Introduction and first content post in my new series about running Elixir Phoenix apps on Kubernetes are live! I’m describing an opinionated and focused approach that assumes you are already comfortable with Elixir/Phoenix and with Kubernetes primitives, but not necessarily experienced with marrying the two. I can definitely point people to more resources for the latter as need be, but won’t include them in the posts, except as links.
Feedback and questions are very welcome on basically any medium, but you can reach me on Slack, Twitter, GitHub or here on the forum as @shanesveller.
The second content post of my series, covering Docker-Compose and Docker-friendly migrations, seeds and Distillery config providers is live! Our first taste of Kubernetes in Part 3 should follow sometime this week.
Pretty comprehensive and ambitious posts! I noticed that the ‘kube_native’ app has access to the ecto repo while the ‘kube_native_web’ app does not. I’ve never done an umbrella app before so my question is is this the usual way to configure db access in an umbrella app? Just wondering what you would do if you needed the ‘kube_native_web’ app to use the db/repo?
Yes, and as a matter of fact this is how mix phx.new --umbrella will construct your application for you. The super-brief explanation is that you want to have only one umbrella application directly responsible for your Ecto interactions with a given Repo. You have that umbrella app provide an abstraction layer used by your other applications within the umbrella, and they depend on that first one in their mix.exs. This is mostly just a slight variation on Phoenix Contexts which were introduced in Phoenix 1.3 - the umbrella structure just sort of forces your hand a little bit in terms of providing good isolation/boundaries.
The first post that actually touches Kubernetes (and a little bit of Helm is available today in Part 3 of my series, and it’s a dense one! Looking forward to feedback and comments, as always!
