Create a Dockerfile for easier development setup

[ghost]

I'm creating a Dockerfile over at https://github.com/voltagex/wheelmap/blob/master/Dockerfile, hopefully when this is all set it'll make setting up a development environment for wheelmap much easier.

TODO:

• [x] bundle install - thanks @joustava and @nickjj

  Database

• [ ] MySQL setup
  • [x] Use docker-compose to split it into multiple containers
  • [x] Figure out an alternative to db:create commands - This task only modifies local databases. wheelmap_development is on a remote host.
  • [x] Wait for https://github.com/docker/compose/issues/2302 to be resolved

    Pull request

• [ ] move the dockerfile to a new git branch - squash all changes

  Other

• [x] Update README

[joustava]

@voltagex what are the errors?

[ghost]

@joustava if I use ONBUILD bundle install it's silent. I'm going to remove ONBUILD completely because it doesn't seem to give me any advantage. After that I get Could not locate Gemfile

[joustava]

have you tried ADD instead of ONBUILD COPY?

[ghost]

Thanks for that tip, the current master looks like it's working. I'll try setting up MySQL in either this container or another one tomorrow.

[ghost]

Making good progress, I need someone else to test this. I now have a docker-compose file for the whole setup that should launch a MySQL database and wheelmap. At the moment I haven't customised the database build so it won't have the right database there, but it should at least connect

[ghost]

I'm stuck. The database rake steps won't work if the database isn't on localhost. This is hardcoded in Rails 3.2.2 and can't be overridden with an environment variable. It looks like it's fixed in Rails 4, sort of.

I could just install MySQL in the same container as the app, but it's much better and easier to use a separate container - this way I can use the official MySQL image.

I'm also waiting on docker/compose#2302 to be resolved so that the database server hostname stays the same between builds.

[joustava]

@voltagex if you help/tell me with how I should test it, I could take a look. I can run it in a vagrant box e.g?

[ghost]

@joustava If you can install docker and docker-compose on a Vagrant box it's as simple as following the instructions in https://github.com/voltagex/wheelmap#docker - just make sure you clone my version of wheelmap until the changes are merged.

The db rake seed command will fail at the moment and I don't have a workaround. If you can generate SQL that does the same thing I will use that in the Docker script.

As of 2pm AEST I've broken my Dockerfile - I'm rebuilding it against Alpine and putting the database in the same image. This brings the first-download size for developers down from 2+GB (!) to ~300mb.

Okay, that got very complicated. I've gone back to my original Dockerfile but the MySQL setup is tricky. I can't use https://github.com/docker-library/mysql/blob/master/5.7/docker-entrypoint.sh in my file as AGPL3 and GPL2 are incompatible.

If you have any issues with the instructions not being clear enough, that's a bug, let me know.

[ghost]

I'm stuck. We can't run rake db:seed against "remote" databases (i.e. in another container) but Docker really isn't set up to run more than one service per container (e.g. mysqld &, bundle exec server)

[lennerd]

@skade @christoph-buente Can you help out here?

[Xylakant]

I can take a stab at this on monday. Need to set up a dev environment anyways. It's possible to run multiple processes in a single container by using a short script that spawns them (foreman, a mini init, ...), but it should also be possible to use a second container for mysql.

[Xylakant]

db:seed should work against a remote database, however, the current way it's laid out in the Dockerfile won't work for two reasons:

• The database that is added to the container specifies a socket connection
• The container with the mysql server may not be available at build time. The database should be created and seeded at first startup of the container. It's probably even easier to just leave that to the user, since it makes sense to destroy/create the app container without destroying/recreating the database container.

[ghost]

Ping @Xylakant

[ghost]

I am reducing my open-source todo list for the moment - this needs another set of eyes but I am still interested

db:seed would not connect to a remote database for me.

[Xylakant]

I'll just grab that if you don't mind

[Xylakant]

It's possible to run run the db:create command on remote machines by overwriting local_database? in active_record. However, there's a bit of a problem since I'm uncertain that docker/docker-compose always assigns the same IP space to the docker interface.

[Xylakant]

we also have some broken migration that tries to create a primary key with a null component.

[ghost]

However, there's a bit of a problem since I'm uncertain that docker/docker-compose always assigns the same IP space to the docker interface.

When you set up entries for different containers in docker-compose.yml, it should create corresponding /etc/hosts entries that you can rely on.

[Xylakant]

Ok, I sort of have this working, but it needs major tweaking.

First of all it makes little sense to use ADD to add the application to the container. That would mean you have to rebuild every time you do a code change. It's probably better to just mount the app directory as a volume.

I'm also not convinced that creating the database on build is the best option since a single failed migration means no container, no way to run rake etc. However, if we don't have a database the container fails to start up.