pecampelo
Trying to facilitate more prominent and faster usage of Docker
Both in a professional level, with enterprise production apps, and personal projects with others, some people I know have a hard time configuring an elixir application from scratch, specifically inside a Docker container (with or without the usage of docker compose). I gotta say, I honestly totally avoid installing any language whatsoever, and working outside of Docker, getting used to working with others all the time, and deploying to custom k8s cluster.
From where I stand, people getting into the language have a really hard time setting up all the environment variables, dev or test environments locally for a ready up CI/CD, and understanding how to make a proper release within a container.
I would first like to understand whether this is a sentiment for any other folks in the community, or maybe there is something missing from my common understanding, and also from folks around me who work with Elixir in a day-to-day basis. I myself, to be honest, don’t have much of a hard time since I was the one who configured most docker images based on the Elixir docker hub images, as well as some other config, but when most devs hit the barriers of
- `rebar`
- the `/rel` folder
- setting up `ENCRYPTION_SALT` and `LIVE_VIEW_SALT`
- setting up a project to run a `phx.server` vs. generating a `hex` dependency…
- setting up an Application depending on the use of the deps involved (PubSub or not with Redis adapter, how should one setup locally?)
Obviously, this is empirical knowledge of sorts. I state that even senior devs right beside me often resort to copying an existing project, instead of doing the setup from scratch, customizing to their needs, and leaving stuff inside the project that they didn’t need in the first place. I don’t know how clear I made myself to be, let me know if more examples could illustrate my point or I made my point across.
My idea, therefore, in order to facilitate adoption of Elixir, is to extend Phoenix, or maybe its generators, to provide early adopters or even a CLI that generates a project fully set up with the latest dockerhub image, separating images for development/test and production, with a `docker-compose.yml` setup, so a faster creation of projects is possible. Again, I am looking for validation of this idea, so maybe I am utmost wrong and this is a minor sector of the community that I am looking at. Of course, everyone here who builds macros and works with metaprogramming already will know it by heart, but I am focused on the entry-levels and mid-levels mostly.
If the idea is considered adequate and valid for the Phoenix core team, I am open to develop it myself from scratch, and open to suggestions on how to do so. I already have some idea of it ready, but I am just looking to fish right now.
Most Liked
rhcarvalho
There’s already mix phx.gen.release --docker for the deployment situation, and it serves as a starting point, not trying to serve everyone out of the box, because there are multiple ways to go about deployment (many documented in HexDocs).
For development, the general stance of the Phoenix team has been encouraging developing outside of Phoenix, for example by creating an Igniter installer to do what you’re proposing. If it turns out a major success within the community it can be added later to Phoenix if necessary. Removing parts, on the other hand, is much harder.
Popular in Proposals: Ideas
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









