You may be interested in a guide I wrote as part of the new docs in 2.0, Deploying to AWS. It pretty much walks you through setting up your own “Heroku in AWS” architecture, i.e. you can git push origin master and have changes rolled out to production automatically. With some minor adjustments you can tweak the architecture to support staging + production, with a manual approval step for deploying staging to prod, though I haven’t covered that yet in the guide - but it’s pretty straightforward once you have some familiarity with CodePipeline and CloudFormation.

what is your recommendation for how to go from zero to “perfectly comfortable deploying a production app, replete with staging/testing/prod/etc. environments, and understanding the benefits and tradeoffs of terraform/ansible/docker/kubernetes with respect to real-world elixir deployments?

That’s a huge question haha. It depends entirely on your comfort level with ops tasks, e.g. spinning up new infrastructure, configuring it, etc. If your only experience with operations is deploying to Heroku, there is a lot to learn before you will feel comfortable with owning the whole stack - even ignoring setups using stuff like Kubernetes/Mesos/etc.

Even though it’s a lot to learn, you don’t have to learn it all at once to be able to deploy things. If you can swing it, I would get budget to be able to experiment in AWS with different services - try things out and see how what works and what doesn’t. Even if you can’t get budget from your company, there is a lot you can do just with the AWS Free Tier - it is a bit more limited than what you can do otherwise, but you can experiment with a lot of things. I had a lot of ops experience already before I ever touched AWS, but I got proficient with AWS by doing the above - just experimenting with the free tier. The bottom line is that you start with doing things by hand, spinning up servers with the config you need, deploying your app - once you comfortable at that level, it’s really all about automation; how do you take the slow or error-prone or repetitive bits, and have code do the work for you. This is ultimately what all of the tools you listed are about.

I’m personally not a fan of Terraform, I use it when I have to, so I won’t say much about that - I would recommend using either the cloud provider’s tools (e.g. CloudFormation), or something like Salt/Ansible/etc. Speaking of Salt/Ansible and so on, as far as moving from doing everything by hand, to automating things, they are a great set of tools to get some easy wins; they are basically automating the exact same things you’d do by hand, so they “fit in your head” fairly easily.

Docker (and more generally containers) and the orchestration tools you use with them, are intended to solve a few problems, one of which is deploying apps with different (sometimes conflicting) software requirements/dependencies to some set of machines, and using the resources of those machines in the most effective way possible. They automate failure recovery and scaling, by spinning up new containers in response to crashes or metrics respectively. By abstracting the resources the containers run on, you can add more container hosts transparently, move containers to other hosts, etc. This level of abstraction has benefits when you are operating at scale, or operating multiple applications/services with different teams and requirements. Docker of course is also useful as a development tool, since you can spin up an application which is identical to how it will run in production (sans config differences), and is one of the reasons why using Docker in production is so popular - ideally, no more “but it worked on my machine!” (of course there are still ways this falls apart, but I digress).

So, all of that to say, my recommendation is to start simple, and work your way into “fancier” setups as you need to. As you gain familiarity with different parts of the infrastructure stack, learn how to automate what you can, and you’ll find that the various tools to assist in that automation will make a lot more sense along the way. The tradeoffs will become much clearer when you have specific goals you are trying to achieve. Trying to start with something like Kubernetes without understanding what goes on underneath it, and what it is trying to solve for you, is going to end in a lot of pain, in my opinion anyway. As far as Elixir goes, it can be deployed anywhere really, no specific infrastructure is going to be “better” for Elixir than another, that comparison can only be made in terms of the needs of your application, or the costs involved, including the time required to maintain the infra.

At DockYard, we use releases, but as far as infrastructure goes, it varies from project to project, depending on client needs and the needs of the specific project. Not very helpful, I know

I’ll keep an eye out in there, in case there are any questions

Thanks for clarifying, I think I misunderstood what you were asking previously.

You would use app env to store the configuration, but the overall scheme remains more or less the same - rather than pushing config down the supervisor tree (which you would still do for the non-request related parts of your application), you would fetch the config from the app env at the boundary of the system (e.g. via a plug), and add configuration to the context which is passed along with the request.

When you reach a point where you need to do some work outside of the request context, you attach the configuration to the context used for that work. This is pattern is fairly common. For example, it is the recommended approach for such things in Go, via Context - which is an abstraction that works beyond just configuration (it can be used for tracing in particular, amongst other things).

So to restate things - you can use the application env for storage, that is it’s purpose; but you shouldn’t be using it like a context. Push config into app env during boot via a config provider, or some other means; then pass the configuration structure down your supervisor tree, or fetch it at the boundaries of your system, and pass it along in a dedicated context structure; then reach into that structure for specific values - but don’t sprinkle Application.get_env/3 all over your code base.

Hopefully that better answers your question, but definitely let me know if there are still questions or parts lacking clarity!