I would probably suggest Kubernetes.
You can setup a pipeline that will push your Docker build to building pipeline (I don’t know the name for AWS as I use GCP) and then roll out to all pods.
Clustering is quite easy this way as well.

Thank you. As for Kubernetes, is they any packages or official documentation on this topic?

I don’t have to use AWS Elastic Beanstalk. I can possibly use Kubernetes on another hosting provider. What I am looking for is auto scaling based on load (web application).

Just a few sources:
https://medium.com/@chargio/creating-a-simple-elixir-phoenix-application-to-deploy-in-kubernetes-2eff2c8e367c

I don’t know of any official documentation specifically for Elixir, but I’d use Docker to deploy on Beanstalk. You can use the mix phx.gen.release --docker task to generate a suitable Dockerfile and then follow the official AWS documentation to deploy a Docker image to beanstalk. I’m sure AWS also has docs and guides to automate this with CodePipeline.

@Blond11516 thank you! One more minor question, how do you deploy and redeploy code changes? Do you do a git pull inside Dockerfile?

Do you do a git pull inside Dockerfile?

No, that’s not really how Docker containers work. The basic idea is that you, as the application developer, write a Dockerfile which describes how to build, configure and start your application. You then use this Dockerfile to build a Docker image (through the docker build command). This image is a bit like a small virtual machine with your application and its dependencies baked in. Finally, you push your image to some repository and ask your cloud provider to deploy this image to a server.

The goal behind this is that images provide a reproducible deployment environment that is built from scratch every time. This means you can take your image and deploy it as many times as you want, on any server you want from any provider you want and it should work the same every single time. This is in contradiction to VPS-based deployments, where you have a single server that you configure manually and push updates to, which often ends up with the server holding all sorts of hidden dependencies and configurations that can be extremely hard to reproduce if you ever need to migrate or scale to another server.

Now, because we want reproducible builds from scratch, updating the application usually means building a whole new image with our updated code and deploying that new image to replace the old one. The exact way to do this will depend on the service you’re using to host your app.

With all that said, I’d recommend you avoid deploying to AWS if you can. AWS is a very complex system that’s more tailored to bigger teams or experienced developers who want fine-grained control over their infrastructure. Because of that, their documentation is honestly pretty hard to follow if you don’t already kind of know what you’re doing.

I’d recommend looking at smaller infrastructure providers with more focused and beginner-friendly offerings. fly.io is very popular in the elixir community for very good reason imo. They have a dedicated guide for Elixir (although the deployment process is basically the same as with any other stack) and it lets you deploy and update an app with just a couple of commands.

Thank you. I have spent some time in the meantime to learn more about Docker. Actually I have deployed my first small application using Docker on a Kubernetes cluster on Linode! Looks great. Seems that it is easier and cheaper to do that using Linode. I will surely check out your suggestions. What is important for me is the auto scaling features of either Kubernetes or AWS Elastic Beanstalk,

Deploying to Elastic Beanstalk is fairly easy (probably the easiest method to deploy something on AWS). As mentioned previously; you can have a Docker image set up and do the rest from the CLI. You can also run the Beanstalk CLI to trigger the build (like you would do from your machine) from your CI on code changes (after a PR gets merged, etc).

However, I must say that If you are going the Elastic Beanstalk route be aware that you are in for a world of pain™️ if you have to deal with distribution down the line - at least if you intend to use any of the standard libcluster strategies (IIRC, EB does not support exposing multiple ports when you use Docker).

Also, If you are using automatic autoscaling and you have shared state for stuff like authentication (using ETS for instance), you might get all sorts of problems because the autoscaled instances are not aware of each other.

PS.: I think the DNS cluster strategy or the Postgres cluster strategy could help with that, but I honestly haven’t tested it on EB yet.

Thank you. How would you deal with that ? Simply using Kubernetes instead of AWS Elastic Beanstalk?

I advise you to try creating a cluster with the new strategies for autoscaled instances (links in my previous reply) and see if that is going to work. If everything works, keep using EB; it’s a lot less work than setting up K8s overall (I mean if you don’t need to).