Skip to content

Development with Docker

Jump to bottom
Archonic edited this page Jan 14, 2021 · 12 revisions

Debugging

Developing with Docker is just as comfortable as rbenv or rvm and the typical rails s and binding.pry or byebug workflow, and I find it more comfortable than foreman.

After getting the docker machines and services running with docker-compose up, you can attach to an individual service with:

docker attach limestone_{service}_1

where {service} could be web. This will follow the server output and using pry or byebug will be interactive. You could also run docker attach limestone_sidekiq_1 to attach to the background processor.

Solve Docker Clockdrift

Integrating with outside services like Stripe, you may get a 400 Bad Request response with the message "Timestamp outside the tolerance zone". On Mac OSx, the host machine sleeping can cause a clock drift with the Docker machine. Restarting the Docker daemon (from the notification bar) will set the Docker machine time to the same as the host. You can ensure the host has the right time with sudo ntpdate -u time.apple.com.

Commands

To run rails/rake (same thing now) or bundler, you can use

docker-compose exec {service} rails ...`

For example, docker-compose exec web rails routes or docker-compose exec web rails c.

Bundler

Just running docker-compose exec web bundle will put the machine's Gemfile.lock in a bad state when restarting. The image will also need to be rebuilt with docker-compose up --build. It won't take as long as it did the first time because of cached Docker layers, but it will need to run the entire bundle step over again (a downside to Docker).

Stopping Services

To stop services, ctrl+c from the terminal you wrote docker-compose up from will send the terminate signal to all running processes. There's a bug in Docker where sometimes it will instead output ERROR: Aborting. In this event, running docker-compose down will kill the still running processes.

To start your environment over, you can delete all volumes while shutting down with docker-compose down -v. This will delete your database and return your disk to its original state. All uploads in the storage folder would be removed.

Redis startup time

Redis is configured to use an AOF (Append-Only File) for persistence. This means that it writes all diffs to a file to reconstruct the current state. Over time redis will take longer to start up which can cause the Sidekiq service to fail on startup. There is a sleep command in config/inititalizers/sidekiq.rb to wait for the AOF file to be loaded since docker-compose only has knowledge of if Redis started, and not if it's ready to receive commands. If the redis service starts to take longer than the sidekiq sleep, you can rewrite the AOF file by running:

docker-compose exec redis redis-cli -a yourpassword then BGREWRITEAOF

Running out of disk space

Docker images can occupy a lot of space over time. You can clean up unused resources with the command docker system prune. If you want to delete everything, including resources still being used (this includes your database, redis data and uploads), you can use docker system prune -a.

You can manually clean up Docker images by listing them with docker image ls and delete them with docker image rm {IMAGE ID} {IMAGE ID}....

ENV Variables

In development, the .env file is used to inject environment variables into the image using Docker Compose. This means you need to restart (ctrl/cmd + c & docker-compose up) for your edited .env file to take effect.

For the test environment, you can use the Jet CLI tool for Codeship, or for CircleCI you can enter ENV vars in the project settings.

First time setup of Jet CLI goes like this:

  1. Install the Jet CLI. On Mac you can do that with brew cask install jet.
  2. jet generate will make your codeship.aes file.
  3. Customize and rename your .env-example file as .env.
  4. jet encrypt .env .env.encrypted will encrypt your .env file and save the result to .env.encrypted. You can keep this file in your source control safely.
  5. Remember to keep your .aes files and .env out of source control. If you accidentally commit and push them, roll all keys and secrets within, and remove any sensitive files. Even if the repo is private.

With the .env.encrypted file in place you're now able to hook up Codeship testing to your repo - codeship-services and codeship-steps.yml are already in place. You can run a local version of these tests with jet steps. This replicates the full cloud test environment locally 👍.

Learning More

If you want to know more about how Docker works (it's pretty neat), I recommend the Dive into Docker course by Nick Janetakis.

Clone this wiki locally