Thanks for response! Sure, I'm down with AWS lock-in, for the sake of argument.
But how do you manage this EC2 fleet and collection of other AWS services? Changes happen -- new version of your local software, change your mind about some configuration, new version of a database, whatever.
OK, it's immutable. But I still need to launch a new EC2, and get everyone else that's supposed to know about it to know about it and start talking to it instead of the old one (or get public traffic to go to it or whatever), and then take down the old one once it's safe to do so. (I also need to figure out how to construct it as immutable).
Purely manually? Just manual operations in the AWS console?
There may be an obvious answer here I am missing not being familiar with the tools. What can be overwhelming here is figuring out the "right" way to orchestrate this stuff, there are so many options (or sometimes you can't find any options but suspect you are not looking in the right place) and so many partisans. One reason for kubernetes popularity is the succesful awareness marketting, I've heard of it and know it is supposed to solve these challenges I'm having and don't really understand what the options are and am overwhelmed trying to figure it out... but k8 seems popular, it must be good?
Your CI pipeline can build an AMI image with integrated Docker image, and a simple systemd script to start it on boot.
Deploy step would just be to upgrade AutoScalingGroup with the new AMI, in a rolling fashion with CloudFormation.
---
However, in most cases I'd recommend going with ECS + Fargate, where you can just deploy your Docker image, and don't have to care about the underlying virtual machines.
---
If you want to go K8s route, EKS + Fargate, (or if you want to go cheaper, EKS + EC2 Node Groups), are the best way in most cases, but you need to be aware that you will have to keep an eye on upgrading EKS versions, Helm charts, and other resources you add to the cluster.
I'd say Kubernetes is a good tool if you need it, but otherwise I'd start with something that doesn't require any maintenance on the ops side.
This. I'm not some Unix sysadmin type who wants to do everything manually. But the AWS features work out of the box for basic deployment, scaling, etc. and Kubernetes seems to just add unnecessary operational complexity without any value if you don't need any other features and are okay with AWS lock-in.
The canonical AWS answer here is: Elastic Beanstalk.
If you use a CI tool, it probably has a CD counterpart which can pipe a passing build directly to EB.
Or you can deploy manually from your repo with "eb deploy".
In either case, AWS will automatically bring the app up on new instances, and test them. If everything looks good, the load balancer will direct live traffic to the new instances, and then spin down the old ones.
But how do you manage this EC2 fleet and collection of other AWS services? Changes happen -- new version of your local software, change your mind about some configuration, new version of a database, whatever.
OK, it's immutable. But I still need to launch a new EC2, and get everyone else that's supposed to know about it to know about it and start talking to it instead of the old one (or get public traffic to go to it or whatever), and then take down the old one once it's safe to do so. (I also need to figure out how to construct it as immutable).
Purely manually? Just manual operations in the AWS console?
There may be an obvious answer here I am missing not being familiar with the tools. What can be overwhelming here is figuring out the "right" way to orchestrate this stuff, there are so many options (or sometimes you can't find any options but suspect you are not looking in the right place) and so many partisans. One reason for kubernetes popularity is the succesful awareness marketting, I've heard of it and know it is supposed to solve these challenges I'm having and don't really understand what the options are and am overwhelmed trying to figure it out... but k8 seems popular, it must be good?