71–80 of 101 posts
We use docker as part of our CI, because that's what Gitlab uses for our CI system. It works very well. Of course we could use podman locally (and I do on some machines), but Gitlab will still be using docker for us.
Earlier quoted context omitted.
Pretty much I worked for an e-commerce, leader of their market, that used no Containers for the past 3 years. CI produced agnostic packages, which were deployed with Ansible in any environment and auto-scalable using Golden AMIs, EBS Snapshots and AWS ASG. Almost the same concept, but way less complex. We contemplated moving to ECS/EKS to stay "current" and to make test/development environments easier to create, but…
I can't help but feel that the drive towards docker-style containerisation was fueled by nothing more than the fad for developing on OS X. If you've got an environment where the devs are working on the same OS as production, it becomes much easier to adopt OS packages (whatever flavour that is) as the deployment mechanism, and as a side benefit it becomes easier to set up the dev environment in the first place. I've…
And even if I didn't have those constraints, I'd still use containers in production because it just makes testing and deployment so much less of a headache.
The real world is still very much using Docker. Infact a few companies I've interviewed with this year aren't even using any kind of container setup and they're doing just fine and making money. This kind of article just adds to the Jonesing-for-shiny-things mentality that really doesn't do the engineering world any favours.
This is a great precautionary tale to founders and an awesome example of hubris at play.
Docker's biggest problem was that they provided tremendous value with their opensource product, leaving few to have any justifiable reason to pay them money.
They courted Riot Games for years, until finally they flat out told them they would never see a penny from them. There are many things that can be learned from a business perspective here...
> If you’re (only) a docker expert, you’re in troubles right now. There are no more jobs looking for docker expertise and you’re dangerously close to unemployable. > Kubernetes has succeeded where docker failed. Management buy-in. This must be one of the silliest articles I've read in a long time. Computer science and engineering does not revolve around the latest devops flavour du-jour. It will be something else in…
Job postings most definitely do.
And yet I still have to deploy my first Kubernetes setup and have used Docker multiple times ... Is there some kind of "Kubernetes-light" out there? So something like in-between running services like NGinx and Postgres on bare Linux machines and having this (I think complex) Kubernetes setup? It's important to say that I don't need any scaling capabilities (apart from maybe some load-balancing in case of a machine er…
easiest way is just start experimenting with GKE on google cloud, and see if it has value to you. Don't bother trying to deploy and manage it before you've kicked the tires. Out of the box its quite good, depending on what you are doing, once you have cert-manager issuing you free certs, linkerd managing a service mesh, and stackdriver giving you an entire ops stack, its a bit hard to go back
It gets harder and harder to find a stack that doesn't rely on it.
At my company, we chose to use ECS/Fargate when possible. It integrates nicely with SSM Parameter Store for config and secrets, and has a simple service discovery feature based on DNS.
A few services run on EC2 + ASG, using AMIs build with Ansible and Packer.
Are we missing something by not using Kubernetes? Is the experience so amazing, compared to ECS? I don't care about vendor lock-in.