A dockerized Phoenix development and runtime environment.
I have been working on a long-running personal Phoenix project since Phoenix 1.0.2. Over the past year and a half or so, Phoenix and Elixir have undergone numerous changes, and some of them (okay most of them) broke my application code. Things really went south after I found myself working on multiple different projects that were built on different Phoenix versions. This reminded me a lot of the early Ruby and Rails days (and fighting rbenv and bundle).
This project was conceived to deal with the issues of running different Elixir and Phoenix versions and supporting the development of apps built with different Elixir and Phoenix versions.
After cloning this repository, open the folder in Visual Studio Code's Remote Extension to get a full Development Environment (with PostgreSQL Database) spun up automatically.
See https://code.visualstudio.com/docs/remote/containers for more details.
It's so simple: just clone this repository.
You can specify a particular Phoenix version by targeting the corresponding release tag of this repository.
For instance, for a dockerized development environment for Phoenix 1.5.7 you could run:
git clone -b 1.5.7 https://github.com/nicbet/docker-phoenix ~/Projects/hello-phoenix
Follow this Github Gist to prepare a minimal Docker release image based on Alpine Linux (about 38MB for a Phoenix Webapp).
Navigate the to where you cloned this repository, for example:
Initialize a new phoenix application. The following command will create a new Phoenix application called
src/directory, which is mounted inside the container under
/app(the default work dir).
./mix phx.new . --app hello
Why does this work? The
docker-compose.ymlfile specifies that your local
src/directory is mapped inside the docker container as
/appin the container is marked as the working directory for any command that is being executed, such as
NOTE: It is important to specify your app name through the
--appoption, as Phoenix will otherwise name your app from the target directory passed in, which in our case is
NOTE: It is okay to answer
Ywhen phoenix states that the
/appdirectory already exists.
NOTE: Starting from 1.3.0 the
mix phoenix.newcommand has been deprecated. You will have to use the
phx.newcommand instead of
mix deps.getwill fail!
Copy your existing code Phoenix application code to the
src/directory in the cloned repository.
src/directory won't exist so you'll have to create it first.
docker-compose.ymlfile defines a database service container named
dbrunning a PostgreSQL database that is available to the main application container via the hostname
db. By default Phoenix assumes that you are running a database locally.
Modify the Ecto configuration
src/config/dev.exsto point to the DB container:
# Configure your database config :test, Test.Repo, adapter: Ecto.Adapters.Postgres, username: "postgres", password: "postgres", database: "test_dev", hostname: "db", pool_size: 10
When you first start out, the
dbcontainer will have no databases. Let's initialize a development DB using Ecto:
If you copied an existing application, now would be the time to run your database migrations.
Starting your application is incredibly easy:
Once up, it will be available under http://localhost:4000
To run commands other than
mixtasks, you can use the
./run iex -S mix