3 ms·
At my workplace we use Docker to run services, but there is no container orchestration like Kubernetes. An AMI bakes in some provisioning logic and the containe
by dolni 5y ago
At my workplace we use Docker to run services, but there is no container orchestration like Kubernetes. An AMI bakes in some provisioning logic and the container image. Autoscaling does the rest.
Even without orchestration, I argue containers are useful. They abstract the operating system from the application and allow you to manage each independently. Much more easily than you'd be able to otherwise, anyway.
Plus you can run that image locally using something like docker-compose for an improved developer experience.
- iangregson 5y agoI'm in this spot too. It's looks increasingly likely that an orchestration layer is in our near future. But we've got pretty far with this approach.
- dolni 5y agoWhat factors are causing you at container orchestration as opposed to continuing with your current strategy?
- brimble 5y agoI tend to use Docker heavily as basically just a cross-distro, isolated package and process manager that also presents config in a reasonably consistent manner. It's wildly better than dealing with "native" distro packages, unless you are all in on doing everything The Correct Way on a particular distro and have tooling in place to make that not suck. That it happens to use containers barely matters to me.
- zokier 5y ago> An AMI bakes in some provisioning logic and the container image That does sound bit weird setup to me; with something like Packer building an AMI is almost as easy as building a Docker image with Dockerfiles so the benefits of using Docker seem quite slim?
- dolni 5y agoNah, Docker still has lots of benefits. You can run a Docker image on a developer system, using docker-compose, and it could even be the exact same one running in prod. That takes a TON of variables out of the equation.