Should I develop my app in docker from the start or later when i have the dev version?

Chat & Discussions Discussions
, ,
1

Hi everyone,

Should I develop my app in docker from the start or later when I have the dev version?

What are your experiences so far regarding this subject?

Thanks in advance

2

That really doesn’t matter, it’s very easy to add docker later :slight_smile:

4 Likes
3

Or you can realise that you do not need Docker at all :wink:

4 Likes
4

I recently had an experience where I built my MVP after a month of working on it. When deploying to AWS using Docker I had 503 error. I spent days debugging and eventually had to retrace all the steps I took developing. It turned out it was more than one issue. Moral of the story is: deploy early, deploy often.

As far as building/using Dockerfile, I only use for deployment on production server. On localhost I just use ‘mix phx.server’

2 Likes
5

I have some concerns about deploying early when it comes to SEO.
With google the first meeting counts(google crawler)

Thanks for sharing @bigbassroller

6

In my case I do because, I want to build a CI,CD pipeline for commits.

1 Like
7

Do you have a tutorial or article on step by step how to do this?

Thanks @Rainer

8

Yea I think about that too. To mitigate you can have .dev subdomain, have server level auth or only have your IP whitelisted.

1 Like
9

Thanks for sharing some pointers and solutions.

10

I use always docker for my development workflow, no matter what programming language :wink:

So in my opinion it’s a must have, because I can literally combine any version of Erlang/Elixir/Phoenix/NodeJs/Postgres/LinuxFlavour and throw them away in the blink of an eye without messing with my Operating System.

An example of my elixir-docker-stack-defaults on the project I am working on this moment:

EDS_STACK_NAME=phoenix
EDS_STACK_BUILD_SOURCE=git
EDS_APP_IP=127.0.0.1
EDS_APP_HTTP_PORT=4000
EDS_CONTAINER_HTTP_PORT=4000
EDS_APP_HTTPS_PORT=4001
EDS_CONTAINER_HTTPS_PORT=4001
EDS_OS_NAME=debian
EDS_OS_VERSION=stretch
EDS_ERLANG_OTP_VERSION=22.2.1
EDS_ELIXIR_VERSION=1.9.4
EDS_PHOENIX_VERSION=1.4.11
EDS_PHOENIX_COMMAND=phx.server
EDS_DATABASE_IMAGE=postgres:11-alpine
EDS_DATABASE_USER=postgres
EDS_DATABASE_COMMAND=postgres

Yes I know you have other tools, but they mess with the Operating System. My approach of using Docker keeps my OS in a pristine state :slight_smile:

8 Likes
11

Awesome Thanks for sharing @Exadra37

1 Like
12

I wrote some things about using docker:
A simple introduction to developing Elixir on Windows with Docker
Create a Phoenix app using Docker
Deploy a Phoenix app to Microsoft Azure with Docker
Not sure something of that suits your need, but maybe there’s something helpful :slight_smile:

4 Likes
13

Thanks for sharing these articles, they really help.

14

I prefer developing the app without Docker and running a Dockerized Elixir release in prod.

I think the biggest thing here is how you pass the configuration to your app. When in production, it’s most likely going to read it from ENV. In such cases I make it do the same when running in dev mode - I recently switched to using .env files. With that out of the way, Dockerizing the app seems pretty straightforward and I never had issues with non-Dockerized vs Dockerized version.

Here’s a good Dockerfile to get you started.

1 Like
15

My default stack for last couple of years is to use docker-compose for local development and Docker Swarm for production if you want to be able to manage it without dedicated DevOps/SRE team.

Swarm and compose have almost the same configuration and quite easy to learn / understand.

Development inside Docker image really helps to have the same environment / os version on the local server and production and you don’t have to install many software packages as postgres / elasitc / elixir locally. I use it for frontend, elixir, ruby and any other toy projects.

At my company (dev shop) ~100 devs it kinds of default approach and you can expect to enter any team, run docker-compose up and get your project running. You can start contributing within couple of hours.

One minor issue with local development on non-linux systems is your filesystem will work slower due to file-sync mechanism. If it’s really an issue (it will be eventually with projects of decent size if you’re using “slow” languages like ruby/python) you can use docker-sync tool to make your filesystem synchronisation work faster.

2 Likes
16

Maybe you are in a MAC computer, because in Linux that’s not an issue.

1 Like