Not really, the value of containers that most people have seen is that it's just a more portable package. It's easier to move between environments in a consistent way. If I do that with fancy orchestration, shell scripts, or configuration management largely doesn't matter. I can get most of the advantages with shell scripts.
Amazon is extremely data driven. If their attitude is lukewarm at best then you might consider the market is lukewarm at best.
People take for granted that the value of k8s has been proven. It has not. The value of containerizing your application is clear and has been realized over and over again. The jury is still out on k8s.
There's a sad truth that many of us engineers do not want to accept. The most successful solutions are ones that do not require quality or diligence from the practitioner. There are absolutely better way to do things than Docker. Pretty much everything about Docker is terrible, but it solves one problem in a very simple way that most anybody can use. That solution is that it creates a fairly portable software package that is easy to create and run.
Now there are tons of issues in the way things are created and ran with Docker, but they will all be sufficiently addressed over time. By adding enough things around the edges (better orchestration and resource management tools, better security scanners, etc) the ends goals and needs of "business" will be met. In the end you have a messy solution compensated by a series of tools. The pros outweigh the cons.
I've been playing with crosvm and containers (lxd) in ChromeOS for awhile and I've been very impressed at the technical expertise that has been required to bring this to ChromeOS. Now that the terminal app is released I can say (I have a pixelbook and am currently using it), the user experience is really quite slick. This is a very promising platform.
I don't fully buy that explanation. If OpenStack was better they would have already had success on that platform and then would be asking for a bridge between k8s and OpenStack (openstack could easily be a virtual kubelet). Instead people are looking to abandon OpenStack in favor of something hopefully better.
The real reason for these projects (Virlet, KubeVirt, RancherVM) is that OpenStack is too damn hard. Even with all this focus on containers these days people still need an onprem VM solution. But the requirements are really pretty simple for most use cases and the cost and complexity of OpenStack is not justified.
This is really the wrong move. Really sucks the personality out of go. I felt the old brand clearly highlighted the important thing is, and where the most time is spent, is the code
Shameless plug: Try Rancher 2.0 (beta announced today and GA coming in a month). With Rancher we enable all the security stuff by default but try to actually make it usable (which is quite hard). So RBAC, PSPs, network policy is all on by default. We give you quite a bit of tools to manage RBAC and PSP.
If you are managing you're own cluster you really need a guide like this. It's very easy to create a very insecure cluster. People are actively targeting poorly configured k8s clusters too. It doesn't take to long before you start mining Bitcoin :)
I find it odd when I see projects in the GitHub org github.com/GoogleCloudPlatform like this one. Being that the org has the same name as Googles product (GCP) I would not expect experimental or nacent projects. I never know what to expect. Is this an official Google product that will be supported or some experiment by some devs in Google.
I've seen quite a few developers buy and use these with mixed results. One key thing I've seen that people have really struggled with is multiple external monitors. For that to work you usually need some USB C dock which is a nightmare.
Personally I've had much better results with Lenovo T and X series because they typically have more conservative hardware that is better supported by upstream Linux. Also their dock is not USB C.
Wow. It's been about 6 years since I last used j9, but at the time I used it it was extremely good. But I was running on Power, which is it's sweet spot.
I programmed Java for 15 years in mostly eclipse. The past 3 years I've been doing go in vim. Just recently I switched to Gogland for go, which is a full blown IDE. It's been life-changingly good. I forgot just how nice it is to have proper tools that just work. So even in a "simple" language like go, an IDE can make a huge difference if you care to learn it.
When I read this issue I think it just reflects poorly on the author of the issue. I see no reason to assume ill will. Notification of violating the license is definitely needed, but the tone of the issue is uncalled for.
We released some versions for ARM but in the end ARM requires too much effort to support right now. As ARM64 matures and Docker gets full multi arch image support we'll revisit this.
Creator of RancherOS here. Thanks for the interest in our tiny distro. RancherOS was created the beginning of 2015 and at the time was quite a novel concept. We strived to not just use container technologies in a Linux distro but actually package everything as standard Docker containers. Fast forward two years, what we were doing back then is now becoming the accepted practice. Most major distro are adopting more container packaging approaches in the form of flatpak, snap, and containerd. RancherOS 1.0 LTS was just released a couple weeks back and we have started development on 2.0. 1.0 was a bit ahead of the time and honestly had to employ a lot of technics to make it work that we didn't like. With 2.0 we will shift the focus from Docker to containerd, OCI, and LinuxKit which will allow a much cleaner design.
I share your frustrations with CSDs but just because they are moving to GTK3 doesn't mean they will adopt CSDs. Can you refer me to what you saw that indicated they would do this? Or do I misunderstand that these two things are in fact coupled?
While the installation experience of Docker for Mac is very good, the unfortunate downfall of the project is they try to hide what is really going on. You are running a VM and through a series of very clever tricks and fancy technology they attempt to make the VM hidden as though you are running Docker local (like in Linux). This has the side effect of odd behaviors. As a result in my own projects we struggle to support Docker for Mac also.
As I read this again I'm quite confused what this announcement means. The mention of snap package makes it seems like "apt-get install docker..." would be a separate binary. A wild guess would be that 99% of Ubuntu users will never buy CS Docker Engine so will that 99% of users be running the debian/ubuntu packaged docker.io binary that exists today?
Thanks, but this alludes to more operators coming. Why is such a thing really needed. The proliferation of this approach seems like a potential downfall of k8s. Similar to Mesos where a framework is quite powerful, the cost of developing one is too high. This blog post basically implies that k8s base constructs can't run postgres, redis, prometheus, etcd, cassandra, etc. But why? Are we saying that stateful services fundamentally require one off domain specific logic to run in k8s?
I would love to understand the design rational on why a custom controller is needed to run etcd as opposed to leveraging the existing k8s constructs such as replicasets or petsets. While this is a very useful piece of technology it gives me the wrong impression that if you want to run a persistent or "more complicated" work load then you must develop a significant amount of code for that to work on k8s. Which I don't believe is the case, which I why I'm asking why this route was chosen.
The transition away from cloud-init and YAML is really quite odd to me. Nobody enjoys editing JSON files. Forgetting commas, no multi-line strings, no comments, escaping characters in strings, etc. Just reading the documentation of ignition should be enough to illustrate the pain it is to manage multiline content for unit files in an JSON string.
But why abandon the cloud-init format in general? Again, why would somebody want to learn a new configuration syntax. Using CoreOS already requires you to know and use systemd units (most other distros this really isn't required knowledge), so that adds two steps to users learning/using CoreOS.
If a structural engineer builds a bridge that collapses and kills someone, they are liable in one way or another. What if the same was applied to software engineering. That would sure change how seriously you take PII.
Expecting open source doesn't mean I wouldn't pay for it. I co-founded a company that is fully open source, so I do understand that money needs to exchange hands to keep this industry flowing. I just believe in freely sharing ideas.
Yes, I'll be excited when the lower bits will be open sourced, as that is what I care most to see (I don't even run Mac/Windows). But in an era when even Microsoft is open sourcing and giving developer tools away for free, the idea that this won't be an open source product is odd.