Hacker News new | past | comments | ask | show | jobs | submit login

I feel like if you have an AMI you don't need docker. If you have docker you don't need a new AMI each time.

For me it's about knowing "what is running." If I can get a binary, docker image, or AMI that lets me know exactly what is running then that's all I need to really care about. For docker without Fargate, k8s, nomad, or etc. it's probably best to simply have an ansible or salt config which pulls down the binary/docker image and updates a systemd service or similar on server group "a" and then you do the same thing to server group "b".

Occasionally you create a new base AMI with updates and expected scripts/agents/etc. and replace the existing instances.

[edit: typo]




Yeah the Docker step isn't strictly speaking necessary for the deployment, it's more for devs with diverse OS's to be able to isolate dependencies on the OS. At JVM shops, the same .jar unfortunately doesn't reliably and reproducibly run the same way across machines. The JVM can only isolate dependencies within itself - if your app requires eg certain /etc/host values, that's something that can and probably should go into a Docker file that isolates dependencies on that, and make that explicit.

As for the AMIs the benefit of always making new ones and storing them (tagging them with the git commit hash) vs mutating a running ec2 is it makes it incredibly simple to roll back - if a release goes wrong, just spin up new EC2s using the previous AMI and viola.

In general we prefer immutability of all things. State is the devil, especially when it comes to "what's running in prod?"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: