Historical errata for Docker for Rails Developers

You can use ‘docker rm 15708ecf4251 577cacdd3383’ instead of ‘docker rm 15708ecf4251 && docker rm 577cacdd3383’ to remove both containers at the same time.

At the end of the page:

“You should see the Rails gem and all its dependencies being installed. This
means we’re now we’re ready to generate our project:”

Should be:

“You should see the Rails gem and all its dependencies being installed. This
means we’re now ready to generate our project:”

• we’re was repeated 2 times.

Second paragraph:

“(technically a pseudoterinal or pty)”

should be:

“(technically a pseudoterminal or pty)”

Missing a period :

“However, manually running the commands is not
easily repeatable We want a reliable, repeatable way of spinning up Rails
servers left, right, and center.”

I think should be:

“However, manually running the commands is not
easily repeatable. We want a reliable, repeatable way of spinning up Rails
servers left, right, and center.”

Actual:
“What we really want is factory — hint hint — for creating these perfect, Rails server containers.”

Should be:
“What we really want is a factory — hint hint — for creating these perfect Rails server containers.”

Missing an “a”, and an unnecessary comma.

Actual:

“We’re using it in our Dockerfile because the official Ruby image that our image builds on top of is based on the Debian — specifically a version called Jessie.”

Should be either:
“…is based on the Debian distribution…”
- or -
“…is based on Debian…”

On point 3: “we sped up our image builds” should be “we speed up our image builds”

Actual:
“Just like a fast test-suite helps by reducing the feedback look…”

Should be:
“…feedback loop…”

The command `$ docker run -i -t —rm -v $PWD:/usr/src/app ruby:2.4 bash` does not work on Windows in either the command prompt or Powershell. It can be modified to `docker run -i -t —rm -v ${pwd}:/usr/src/app ruby:2.4 bash` on Powershell, but I’m not a very serious user of the command prompt, so I don’t know the translation.

This command:
$ docker run -i -t —rm -v $PWD:/usr/src/app ruby:2.4 bash

did not work for me on MacOS (High Sierra). I eventually figured out by googling that I had to enclose $PWD in quotes like:
$ docker run -i -t —rm -v $PWD ruby:2.4 bash

to get it to work.

“For our purposes though, we don’t really care what we use Redis, we care more about how to use it.” should be “For our purposes though, we don’t really care what we use Redis for, we care more about how to use it”.

After running docker-compose stop and then docker-compose up -d, I found that the Redis container had maintained the hit count (I verified that both containers were stopped before bringing them back up). So when I refreshed the web page, it said “This page has been viewed 6 times” and it continued counting up from there. I assume that this is expected behavior for Redis within a stopped container, but wasn’t totally sure because the text in the book suggests the counter would have started over.

Actual:
“(Compose uses the <app-name&gt;_default naming convention.)”

Should be:
“(Compose uses the _default naming convention).”

Actual:
The option -h redis says “connect to the host named redis. This only worked…

Should be:
The option -h redis says “connect to the host named redis”. This only worked…
(Missing ending quote mark)

I might be doing something wrong…or there is something wrong with the example on this page. After I set up the volume declaration and go through the steps to try to create the persistent volume…and then delete the container…and recreate the container…my database is gone.

My guess is that /var/lib/postgres/data needs to exist and be writable by the owner/user of the docker-compose process…namely my personal account.

I’ll dig further tomorrow but the example might need some supporting rules regarding path selection etc.

WORKDIR statement should be

WORKDIR /usr/src/app/myapp

As the app was created with “rails new myapp” inside /usr/src/app?

I believe in the second paragraph, “feedback look” should be “feedback loop”.

After pressing Ctrl+C to shut down the container, it is no longer possible to start it, because: “A server is already running. Check /usr/src/app/myapp/tmp/pids/server.pid.”

The output from docker-compose before ctrl+c:

Creating dockerrails_web_1 … done
Attaching to dockerrails_web_1
web_1 | => Booting Puma
web_1 | => Rails 5.2.0 application starting in development
web_1 | => Run `rails server -h` for more startup options
web_1 | Puma starting in single mode…
web_1 | * Version 3.11.4 (ruby 2.4.4-p296), codename: Love Song
web_1 | * Min threads: 5, max threads: 5
web_1 | * Environment: development
web_1 | * Listening on tcp://0.0.0.0:3000
web_1 | Use Ctrl-C to stop
Killing dockerrails_web_1 … done

Regarding #83015
The issue is described in the next section on mounting local volumes, but as long as there is no volume mounted, it is not obvious how to get the container running again with no access to myapp/tmp/pids…

The
docker run command we’ve see creates a new container then starts it running

I guess it should be “we’ve seen”

(Compose uses the <appname&
gt;_default naming convention.)

“What we really want is factory — hint hint — for creating these perfect, Rails server containers.”

Should be:

“What we really want is a factory — hint hint — for creating these perfect, Rails server containers.”

Paragraph two, sentence 1 reads … close the feedback look…. I think it should be
…feedback loop…

“Docker’s built-in delivery mechanism means that new team members can go from zero to running app in seconds.” - in seconds is kind of not realistic. In my reality it is closer to “in minutes”. At least one needs to pull some images, which already takes a few minutes usually.

Built date in the Client section of docker version has missed its alignment spot.

Built: Wed Mar 21 23:06:22 2018

Removing containers using their names also works:
docker rm admiring_brown competent_ardinghelli

and also with a single command instead of combined 2 commands.

I’ve chosen to focus on configuring feature specs in this chapter
since the majority of Rails projects are unlikely to be running Rails
5.1. However, the setup steps are very similar and most of what
you learn in this chapter is relevant to feature tests.

last sentence s/b …" relevant to system tests."

To achieve a long-lived, interactive Bash session inside a Docker container, we have to tell Docker to setup a terminal emulator for us (technically a pseudoterinal or pty), that sits in front of Bash.

pseudoterinal should be pseudoterminal

When describing the Windows installation, you should at least mention the fact that the Windows Installer does not work on the Home Edition, due to the lack of Hyper-V support. Instead you have to use the Docker Toolbox to install Docker on Windows Home.

“So what’s real the solution” should be “So what’s really the solution”

“overlayed” should be “overlaid”

The screenshot on this page should show an incremented count of views. Also, the screenshot on p. 65 should not be pluralized.

The environment block in the docker-compose.yml at the top of the page has a new key and value (POSTGRES_DB). I’m not certain it’s supposed to be there, but it should either be noted as an addition or just removed. We remove it entirely before restarting the database server, so it doesn’t break anything, but it’d be good to remove if unnecessary.

If the “docker-compose down” command actually removes “network” and “volume” resources, in the last paragraph of the page, where it says “…and don’t want to free up space…” it should say “…and want to free up space…”.

If the password has some strange characters, i.e. ]UH{Sl[g{UfL7Q(KYm#0 - this will fail to work:
password: <%= ENV.fetch(‘POSTGRES_PASSWORD’) %>

To make it work we will need to wrap that password in quotes:
password: “<%= ENV.fetch(‘POSTGRES_PASSWORD’) %>”

Please could you explain where those volumes are stored?

volumes:
db-data:

While decoupling data from Postgres container, I would like to suggest that we also decouple gems installed into a volume. This way every time we add/change the gem we do not have to install all of them each time. I did that before using a volume but with a different technique. I will try to do it with the technique used for db-data volume.

In PowerShell, `&&` is not a valid statement separator. stackoverflow.com/questions/2416662/what-are-the-powershell-equivalents-of-bashs-and-operators has some explanation, but it might be good to separate the command using `&&` into two separate commands, despite the elegance of uniting them in Bash-like shells.

Lines in the code are numbered incorrectly. Current line 10 is actually line 8 :-) etc.

expore - did you mean explore?

I would like to suggest that you present techniques for the cleanup of the images left there after docker-compose build. What does it mean for our little laptops if we have dozens of untagged, not needed docker images of which each is over 1GB? Would those take our precious SSD disk space?

Isn’t the Dockerfile WORKDIR instruction kinda wrong because we now have the rails app in ./myapp (we instructed the rails gem to create the new app in there) so now running rails s in /usr/src/app will fail?

I have a suggestion about the second strategy for the advanced gem management.

I found that if I mount a volume as vendor/cache I don’t need to change the BUNDLE_PATH env variable.
So, the mount point looks like this (on the web container)

gem-cache:/usr/src/app/vendor/cache

This is based on this reference:
“While installing gems, Bundler will check vendor/cache and then your system’s gems. If a gem isn’t cached or installed, Bundler will try to install it from the sources you have declared in your Gemfile. ”
bundler.io/v1.2/bundle_install.html

Maybe I’m wrong and am missing something but it seems to be working nicely.

Wrong line numbers.

… it busts the cache for line 8 -> line 10
… in the bundle install step (line 10.) -> line 12

The line numbers are incorrect on the Dockerfile listing on the page. This makes the explanation below the snippet somewhat confusing.

Might be good to add that if the reader sees an error when trying to start the chrome service mapping to their local 5900 port, this may not work if they already have something running there on their local machine. On Mac OS X, this is can happen if the reader has screen sharing turned on in their System preferences.

Before wrapping up Chapter 4, I expect to see a service added to the docker-compose.yml that covers the configuration of a “webpack” service that runs on port 3035 that provide packs, now that these are a major feature in Rails 5.x.

You are saying to set BUNDLE_PATH variable but it’s BUNDLE_GEMFILE that is used :

and set the BUNDLE_PATH environment variable so that Bundler picks up the
Gemfiles from this new location:

ENV BUNDLE_GEMFILE /usr/src/app-gemfiles/Gemfile

The sentence is not finished in the following phrase:
" This means that files created inside the container will be owned by the"

When modifying the Dockerfile to use a Gem Cache Volume as displayed on page 106 of the pdf there is an issue. I got an error about “rails” not being in the path… I solved it by adding “bundle exec” before the rails command, e.g. ‘CMD [“bundle”, “exec”, “rails”, “s”, “-b”, “0.0.0.0”]’ This makes sense as that is the only way that rails is available in the image… But surprised it wasn’t necessary earlier.

There are separate RUN commands in the Dockerfile for apt-get update and the apt-get install here and in the rest of the book. Isn’t it better to have those both in the same command (i.e. apt-get update && apt-get install) so that if the nodejs install is tweaked in the future (to grab a specific version, etc.) it will cache bust the update (or else it’s using an old update possibly looking for a newer version of nodejs that wasn’t available when it was cached) ??

(follow-on to previous erratum for this page). Also just adding to the path would find rails without using “bundle exec”. I noticed this reading the Dockerfile for the ruby images. I added the following to my Dockerfile:

ENV PATH $BUNDLE_PATH/bin:$PATH
ENV BUNDLE_APP_CONFIG $BUNDLE_PATH
ENV GEM_HOME $BUNDLE_PATH

I’m not sure they are all needed but they fixed the error of not finding rails on the path. (I derived these from the way the ruby:2.4 image was setup).

While following the instructions to run the tests for the first time, the command “docker-compose exec web rails spec” did not issue any output. I tried calling RSpec directly with “docker-compose exec web rspec spec” and this time it worked, so you may want to review the correct command.

Comment on L10 of Dockerfile

Currently reads

1. Ensure we install an up-to-date version Node

Should read

1. Ensure we install an up-to-date version of Node

Also, some of the other comments seem to have extraneous # symbols at the end, which don’t align with anything.

I know these are only comments, but everything else in this book is so precise and well thought-out that even the slightest deviation from that really stands out!

The command

$ docker-compose up -d webpacker_dev_server

should read

$ docker-compose up -d webpack_dev_server

as this is the name of the service as defined by the docker-compose.yml file listed on pages 86 to 87.

The text explaining the ENV line in the Dockerfile during “Strategy 1 (bundle add then Commit)” mentions BUNDLE_PATH, but the example source code correctly uses BUNDLE_GEMFILE.

The Docker volume previously created for the PostgreSQL data was db-data, with a hyphen; for the gem cache, it’s gem_cache, with an underscore. Might it be wise to be consistent with naming?

You say to create a file called web and one called database in the dir .env/development. But you do not say what type of files these are, ie .yml or .rb or just a file with no type ending. Would be nice to know what type of file your referring to. Thanks for the book, using it a lot!

The top paragraph states that we can reload /users and the database will still be there. However, because the database files were previously living within the database container (i.e., before the db-data volume was referenced), the migration only applied to the database files within the container, which we just deleted. the bin/rails db:create and db:migrate need to be re-executed once the database container referencing the volume has been recreated. Note that the db:create will again report that myapp_development already exists, based on the database configuration in the environment variables.

In the first paragraph after the feature table, “Swarm vs Docker” should probably be “Swarm vs Kubernetes”

Hi, when setting up the Javascript stuff on a Mac 10.14.1 (18B75) using Docker Version 18.06.1-ce-mac73 (26764) stable I get an rb-inotify resource overflow error for each of the web pack install commands. See output below.

https: //gist.github.com/timharding/96f608d94a6049a987c97e1da4d1913f

I have no idea if that stuffs up the process or not but it is alarming.

The command should be `docker-compose up -d` instead of `docker-compose up -d web`. Since in the previous section where we install the redis gem we didn’t run the redis service by it’s own. The reader will get,

Redis::CannotConnectError (Error connecting to Redis on redis:6379 (SocketError)):

Hello,
I run this command
$ docker-compose run —service-ports web
to start debugging.
But the output says
Cannot render console from 172.19.0.1! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255
Please add to your book clear explanation how to correctly fix this problem,
because I’m tired to find the right solution for this problem.
I’m sure that almost all the readers will have the same problem.

Thank you,
Yurii

To build prod tag image the following command is given :

docker build -f Dockerfile.prod -t robisenberg/myapp_web:prod .

Which, at least for me, fails as precompiling assets requires some environment configuration not available without compose.

KeyError: key not found: “DATABASE_HOST” (Hash#fetch raises when not found)

Giving nil default values solved it, but now I feel a little dumb using fetch to fallback on nil, as simple hash access would to the exact same thing.

host: <%= ENV[‘DATABASE_HOST’] %>

“that let’s us compose” should be “that lets us compose” in the second para of ch 4.

“conatiner” should read “container” in paragraph starting “We could have used exec instead of run —rm”

“capabilties” should read “capabilities” in paragraph starting “Though slower to run”

The docker-entrypoint.sh script should really start with “#!/usr/bin/env bash”, as it uses bash-specific syntax, and /bin/sh is not always symlinked to bash. The script as written will work on macOS and Ubuntu/Debian, but it’s best practice to use env here.

“nfrastructure” should read “infrastructure” in the “configuration management” paragraph.

“Unfotunately, this seems to be a long-standing…”

should be

“Unfortunately, this seems to be a long-standing…”

“frst” should be “first” in paragraph starting “OK, now that we have an image”

“let’s” should be “lets” in paragraph starting “Before we conclude this chapter”

List item 3: missing a full stop at the end.
List item 4: “unambiguoulsy” should be “unambiguously”

“environments” should be “environment” in second paragraph.
“That means, infrastructure” does not need a comma.

The db-creator and db-migrator entries need to be added as children of the services key, but this is not clear from the text. Adding them as root elements causes the deploy to fail.

If using a private registry, “docker stack deploy” fails. It would be useful to mention the need to run “docker login” first, and then to add “—with-registry-auth” to the “docker stack deploy” flags.

This section greatly needs some information on troubleshooting — in my case, myapp_db-creator remains at 0/1, and “docker service logs myapp_db-creator” shows “PG::ConnectionBad: could not connect to server: Connection refused”.

There is no information whatsoever on how to track down things like this, and the “discuss” link leads to a page complaining about the FOSTA-SESTA Act (rather than to a third-party discussion site run by a non-US company, which would be the customer-friendly way to handle this).

Please could we have pointers on how to fix issues like these?

In Dockerfile, I needed to change “WORKDIR /usr/src/app/” to “WORKDIR /usr/src/app/myapp” to run successfully.

Please feel free to close bug #84084 re: adding “myapp” to WORKDIR. Turns out if I had read page 23 I would have placed it in the myapp directory and it would work fine. Thank you.

“part” should perhaps be “parts” in “…they are described and managed as fundamental part of your app”

After completing “docker stack services my app” several times I never got the db-creator or db-migrator to 1/1. I later read on to the next chapter and found “docker stack ps my app” reporting an error saying No such image: macpclinux/myapp_web:latest". This got me to looking at the file ‘docker-stack.yml’ and see that the web was looking at :prod but the creator and migrator were not. I think this could be the problem and that it has to be updated.

The keyboard shortcut for refresh is given as Ctrl-C or Cmd-C — this should be Ctrl-R or Cmd-R.

/app/src/app should read /usr/src/app

This has been reported by other people but not on this page.

>> Here, mounting the local volume meant that the Rails project generated inside the container (within /app/src/app)

Should be … (within /usr/src/app)

1. You fail to explicitly mention to go ahead and create docker-compose.yml

2. If creating docker-compose.yml with textmate it is very difficult to avoid tabs which will break docker-compose, I had to use vi to get it to work.

(the Dockerfile containers the bundle install command.)

should read
(the Dockerfile contains the bundle install command.)

Beginning of chapter 5
“Redis?! What about setting up the database?!”

It’s poor grammar to use both ! and ? to end a sentence. It would be better to change this to:

“Redis! What about setting up the database?”

So there you have it. Our Redis server is up and running, and we can connect to it from a seperate container.

SEPARATE

Ok, we’ve our app is configured for webpacker and React

- remove we’ve

Terrible grammar.

Our web service should already be stopped, and we removed its container earlier, so to create a new web container along with the gem_cache volume, we just do:

Change to read as follows:

Our web service should already be stopped and we removed its container earlier. To create a new web container along with the gem_cache volume, we just do:

For some (possibly virtual) nfrastructure,

should read:

For some (possibly virtual) infrastructure,

Additionaly, when things go wrong,

should read:

Additionally, when things go wrong,

Incomplete sentence and should have a comma after “locally”.

We’ll use this shortly to first create instances running on VirtualBox locally on page 155 and then .

It provides a fully-managed clusters,

should read:

It provides fully-managed clusters,

Using Redis.new in the controller will start a new Redis connection every time for every request. This will not scale well. The solution is to create a config/initializer/redis.rb file and place the following code in it.

redis_url = ENV.fetch(“REDIS_URL”)
REDIS = Redis.new(url: redis_url)

Then, in the welcome controller, change to this code:

REDIS.incr “page hits”
@page_hits = REDIS.get “page hits”

This way, you will always be using the same Redis connection.

I set my REDIS_URL environment var as follows:

For local rails, in an .rbenv-vars file as “redis://localhost:6379”

For Docker, in the .env file as redis://redis:639/0

For Kubernetes in my deployment yaml as for Docker.

docker-compose rm -f database fails because you have saved changes in the docker-compose.yml file that are invalid. Better is to stop the database and remove it before saving the xml file.

On page 179, when I run the command ‘docker-compose build web’ I get the follow error after having updated my Dockerfile like page 177 suggest:
macbook:rails_app_in_docker Rafael$ docker-compose build web
Building web
ERROR: Dockerfile parse error line 9: unknown instruction: ​RUN
macbook:rails_app_in_docker Rafael$

I am on Mac OS Mojave 10.14.2 and on docker:
macbook:rails_app_in_docker Rafael$ docker version
Client: Docker Engine - Community
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:47:43 2018
OS/Arch: darwin/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.0
API version: 1.39 (minimum version 1.12)
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:55:00 2018
OS/Arch: linux/amd64
Experimental: false

In Part 1, section 1, “Generating a Rails App without Ruby Installed”, there is the command:

$ docker run -i -t —rm -v ${pwd}:/usr/src/app ruby:2.6 bash

Instead of ${pwd}, you want $(pwd), so the command would be:

$ docker run -i -t —rm -v $(pwd):/usr/src/app ruby:2.6 bash

This is an extension to #84003 originally submitted by Thomas Battiston. Apparently the issue is related to the command for precompiling assets, requiring several environment variables for completion. Using docker-compose provides them through the .env mechanism, however ‘docker build’ is not aware of those variables.

I could only solve through using several ARG lines in Dockerfiles.prod . It works but it’s not the most elegant solution. Maybe there’s a better way of doing it? I had to provide for the following variables: DATABASE_HOST, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB. I even provided RAILS_ENV=production in order to avoid some message about outdated yarn resources.

5th sentence, “just build” should be “just built”

6th line, “instructions” should be “instruction”

“If you look through the output, you’ll see that steps 1 to 3 all say Using cache .”

Actually, only step 2 says that.

On the 13th line, “collection” should be “mapping”.

In the last terminal session, the command should be `docker run`

Line 19: “the Dockerfile containers” should be “the Dockerfile contains”

6th line, “Ruby server” should be “Rails server”

4th line from the end: “it’s” should be “its”

Line 12 “mechanism” should be “mechanisms”.

Above “Compiling Assets with Webpacker” heading. “Ok, we’ve our app is configured for webpacker and React.”

“is” should be removed.

In the Dockerfile, tee is not really necessary since we’re running the command as root (it’s not prefixed with sudo). We can use a regular redirection character: RUN echo “deb https//dl.yarnpkg.com/debian/ stable main” >/etc/apt/sources.list.d/yarn.list

The “docker run” commands can take a “—rm” option to use throwaway containers.

“Let’s modify our the generated view” should not contain “our”

Bullet number 4, “an run a React app” should be “and run a React app”

"Create the file spec/system/page_views_spec.rb and edit it to look as follows:

Let’s start with this:"

The second sentence should be removed.

“Linux Users: File Ownership” We have not Rails-generated anything here, I’m not sure we need to chown anything.

Not sure we need to chown anything here since we did not generate anything with Rails.

6th line …/gems here is misleading as someone may easily think it refers to a gems directory in the parent directory. I suggest removing the … here.

Code sample can use `rm -f` to avoid the need to check for the file.

Same thing on page 123.

Last sentence of last paragraph does not add anything knew since we have already added an ENTRYPOINT in our Dockerfile on page 122 (bullet point 3)

Code sample contains # START_HIGHLIGHT and # END_HIGHLIGHT

“Put this in your .bash_rc file or equivalent”

It’s .bashrc (without an underscore)

Last line, Dockerhost should be Docker host

“We’re currently maintaining two files in Compose format: docker-compose.yml and docker-compose.prod.yml”

The latter should probably be “docker-stack.yml”

from:
```
expect(page).to have_text(“ENHANCED!”)
```
to:
```
expect(page).to have_text(:all, “ENHANCED!”)
```
When I ran the test without `:all`, I came across error:
```
expected to find text " ENHANCED!" in “This page has been viewed 20 times!”. (However, it was found 1 time including non-visible text.)
```
So I decided to use the `:all` flag. This flag comes from `Capybara::Node::Matchers#assert_text`, which `have_text` wraps.
```

In the light green Info box, the line
“See Chapter 9 for more details.”
should be
“See Chapter 10 for more details.”

In the green info box the same erratum as before:
the reference to Chapter 9 should be Chapter 10

Same as the last two.
The green info box refers to Chapter 9 instead of Chapter 10.

Another green info box referring to Chapter 9 instead of Chapter 10

```
curl –4 http :// localhost :3000 / welcome
```
should not use `localhost` since we are using a local swarm backed by virtualbox instance. Perhaps use `192.168.99.100` or ``.

Running command:
```
docker-machine create \\
—driver digitalocean \\
—digitalocean-access-token $DIGITAL_OCEAN_TOKEN \\
—digitalocean-region lon1 \\
do-manager-1
```
results in an error during `apt-get update` due to the default digital ocean image being `ubuntu-16-04-x64`:
```
Error creating machine: Error running provisioning: Error running “sudo apt-get update”: ssh command error:
command : sudo apt-get update
err : exit status 100
```
This may be because the ubuntu 16.04 image provided by digital ocean has stale package lists.
I recommend adding `—digitalocean-image ubuntu-18-04-x64` flag to the docker-machine create command. The 18-04 image doesn’t have this problem.

I’m using MacOS 10.13.2 with Docker Desktop 2.0.0.0-mac81

After following all the steps, and attempting the ‘docker run’ command for the first time, I see the following error followed by a stack trace:

#<LoadError: Error loading the ‘sqlite3’ Active Record adapter. Missing a gem it depends on? can’t activate sqlite3 (~> 1.3.6), already activated sqlite3-1.4.0. Make sure all dependencies are added to Gemfile.>

I did some searching, and it appears to be an issue with the most recent stable Rails release - 5.2.2: stackoverflow.com/questions/54527277/cant-activate-sqlite3-1-3-6-already-activated-sqlite3-1-4-0#answer-54729071

I added ’ , ~> 1.3.6’ to the sqlite3 line in Gemfile, updated, re-ran ‘docker build’ and the server then started correctly.

“This tells Docker to copy all the files from our local, current directory ( . ) into
/usr/src/app on the filesystem of the new image. Since our local, current directory
is our Rails root, effectively we’re saying, “Copy our Rails app into the container
at /usr/src/app .” The source path on our local machine is always relative to where
the Dockerfile is located."

The section quoted above is wrong. The source path on our local machine is relative to the docker context supplied to the build command:

$ docker build -t -f

If the -f setting is omitted, docker looks for the file “Dockerfile” in the top-level location of the docker context.

Due to release of sqlite3 1.4.0, Rails 5.2.2 ActiveRecord sqlite3 adapter requires 1.3.x and fails to work with sqlite3 1.4.0, though a new Rails application created through the tutorial will reference it via the Gemfile. The fix is to lock sqlite3 to a 1.3.x version, e.g.

gem ‘sqlite3’, ‘~> 1.3.0’

Then build your docker image.

Following the instructions, I’ve built a Dockerfile, built the image, and asked it to run using the $ docker run line shown n the middle of the page (substituting my image ID for the example).

I get no output about Puma booting, etc.; I do get an error when I attempt to visit localhost:3000 in Firefox:

Puma caught this error: Error loading the ‘sqlite3’ Active Record adapter. Missing a gem it depends on? can’t activate sqlite3 (~> 1.3.6), already activated sqlite3-1.4.0. Make sure all dependencies are added to Gemfile. (LoadError)
/usr/local/lib/ruby/2.6.0/bundler/rubygems_integration.rb:408:in `block (2 levels) in replace_gem’

It appears something in the bundle install process isn’t correct; perhaps the Gemfile is wrong? I tried adding “, ‘>= 1.4.0’” after the “gem ‘squlite3’” entry but that generates an exception in the localhost:3000 page, “No connection pool with ‘primary’ found.”

Not sure how to fix this.

Running “docker-compose build web” on my Mac OSX 10.13.6 emits a warning about line 13 of the Dockerfile:

Warning: apt-key output should not be parsed (stdout is not a terminal)

but this doesn’t seem to affect the rest of the successful build.

I had to login to Docker before docker-compose would work for me. Prior to that I got:

dockerpycreds.errors.StoreError: Credentials store docker-credential-osxkeychain exited with “The specified item could not be found in the keychain.”.

Gemfile.lock is mentioned as already existing but I carefully followed all steps and there is no Gemfile.lock

To create Gemfile.lock, I did this:
$ docker run —rm -v ${PWD}:/usr/src/app -w /usr/src/app railsapp bundle lock

BTW, I’m loving this book. Its been many years since I’ve read a tech book this good (been on it all day and just want to keep going). I’m learning a ton. Thanks for writing it.

Last line of the page:

“all IPv4 address on this machine.”

should be

““all IPv4 addresses on this machine.”

$stdout.sync = true

should be

STDOUT.sync = true

if set, it uses the value of the POSTGRES_DB environment variable as the name for this table

should be:

if set, it uses the value of the POSTGRES_DB environment variable as the name for this database

When using the Gem Cache Volume, the following command no longer works:
“docker-compose exec web rspec spec/system/”, because rspec no longer lives in the app’s ./bin, but moved to /gems/bin.
What does work is “docker-compose exec web bundle exec rspec spec/system/”, but I believe a proper binstub should be added instead.

So, while trying to build Dockerfile.prod, i ended up failing, because the .env environment variables are not loaded, and asset:precompile initialize the app.

I had to add them by end to make it work :/

The alternative way to see the hostname change in the welcome page using the curl command does not work, since the app is not on localhost but on the virtual machine host (in the case of the author on IP address 192.168.99.100). Instead of localhost:3000 it should be 192.168.99.100/ or [enter local-vm-1 ip address here]/

We previously removed

RUN bundle install

from the Dockerfile when discussing gem caches. The production image isn’t going to build properly, because now we’re trying to do

RUN bin/rails assets:precompile

There is no Rails, because we have no gems. I suspect that the concept of a gem cache has been abandoned at this point in the book, but if that was ever mentioned I missed it.

When adding netcat to RUN apt-get, docker does not like the comment on the same line following the line continuation slash; it treats the next line as a new instruction.

Error response from daemon: Dockerfile parse error line 20: unknown instruction: NODEJS

Moving the comment to its own line above seems to work.

docker version 18.09.2

I’m using Rails v.6.0.0.rc1
bin/rails assets:precompile fails when I’m issuing command `docker build -f Dockerfile.production -t prepin/ipakb:f01`

What happens:
- looks like bin/rails command always require database connection but as there are no database available when we running standalone docker build command (not docker-compose build), a new step in Dockerfile.prod — can not be launched successfully.

Workaround
- set default dummy values in database.yml
```
host: <%= ENV.fetch(“DB_HOST”) { ‘none’} %>
username: <%= ENV.fetch(“POSTGRES_USER”) { ‘none’} %>
password: <%= ENV.fetch(“POSTGRES_PASSWORD”) { ‘none’} %>
database: <%= ENV.fetch(“POSTGRES_DB”) { ‘none’} %>
```

$ docker stack deploy -c docker-stack.yml myapp
if we are using private repo, it is required to add —with-registry-auth key, otherwise docker would not access image
docker stack deploy -c docker-stack.yml —with-registry-auth myapp

For MacOS users that have brew installed, you can also do “brew cask install docker”, and you will be setup. I would like to see this added after the first paragraph for MacOS installation.

with Docker 18. 09.2 on the Mac it looks like the “-t” option is required to show command output without buffering.

$ docker run -t -p 3000:3000 a1df0eddba18 \\
bin/rails s -b 0.0.0.0

Or maybe it’s something in my .dotfiles that’s doing this….

I got the following error when executing:

$ docker-compose exec web rspec spec/system/

An error occurred while loading ./spec/system/page_views_spec.rb.
Failure/Error:
Capybara.register_driver :selenium_chrome_in_container do |app|
Capybara::Selenium::Driver.new app,
browser: :remote,
…
desired_capabilities: :chrome
end

NameError:
uninitialized constant Capybara

1. ./spec/support/capybara.rb:1:in `<top (required)>’
2. ./spec/rails_helper.rb:3:in `require_relative’
3. ./spec/rails_helper.rb:3:in `<top (required)>’
4. ./spec/system/page_views_spec.rb:1:in `<top (required)>’
   No examples found.

Finished in 0.00039 seconds (files took 0.18156 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples
———————————————————————————————————————————————

The fix for me was to add:
require ‘capybara/rspec’

to the top of the file spec/spec_helper.rb

I could not find this in the text for the book.

When “Connecting Our Rails App to Postgres” and utilizing the env files.

running the command ‘docker-compose​​ ​​run​​ ​​—rm​​ ​​web​​ ​​bin/rails​​ ​​db:create​’
produces an error because a trailing spaces being added to the env from the file.

docker-compose run —rm web bin/rails db:create
FATAL: password authentication failed for user “postgres​ ”
Couldn’t create ‘myapp_development​ ’ database. Please check your configuration.
rails aborted!
PG::ConnectionBad: FATAL: password authentication failed for user “postgres​ ”

I have confirmed no spaces are present in the env files

Postgres named volume. Asking to run migration after container deleted and recreated.
I followed all steps, added named volume to my database service
volumes:
- db_data:/var/lib/posgresql/data
volumes:
db_data:
It is creating volume but when I delete database container and run it again rails trowing an error and can’t access previously stored User data. it is asking to do migration but once I do it I loose all data

Postgres named volume added
users created
Once postgres container deleted and new one run
Rails is asking to run migration.
I followed all steps, added named volume to my database service
volumes:
- db_data:/var/lib/posgresql/data
volumes:
db_data:

Users records are not available from named volume
once I run migration as rails asking, there is no data

For Rails 6+ you need to install recent version of Yarn and run a rails webpacker:install. Edit the Dockerfile like suggested bellow, and everything runs fine.

NOTE: REMOVE THE *, I was not allowed to add hyperlinks in this code snippet.
See

FROM ruby:2.6

1. YARN repository
   RUN curl sS h*ttps://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add
   RUN echo “deb h*ttps://dl.yarnpkg.com/debian/ stable main” | tee /etc/apt/sources.list.d/yarn.list

RUN apt-get update -yqq
RUN apt-get install -yqq —no-install-recommends nodejs yarn

COPY . /usr/src/app/

WORKDIR /usr/src/app
RUN bundle install
RUN rails webpacker:install

When I try to run the system tests with JS as per your instructions, I get:

Selenium::WebDriver::Error::WebDriverError:
Unable to find chromedriver. Please download the server from
… and place it somewhere on your PATH.
More info at …

I have the following in my development/test block in my Gemfile:

group :development, :test do
gem ‘capybara’, ‘~> 3.7’
gem ‘pry-rails’
gem ‘rspec-rails’, ‘~> 3.8’
gem ‘selenium-webdriver’, ‘~> 3.14’
end

Here is my docker-compose.yml file:

version: “3”

services:
web:
build: .
ports:
- “3000:3000”
- “4000:4000”
volumes:
- .:/usr/src/app:delegated
env_file:
- .env/development/web
- .env/development/database
environment:
- WEBPACKER_DEV_SERVER_HOST=webpack_dev_server

webpack_dev_server:
build: .
command: ./bin/webpack-dev-server
ports:
- “3035:3035”
volumes:
- .:/usr/src/app:delegated
env_file:
- .env/development/web
- .env/development/database
environment:
- WEBPACKER_DEV_SERVER_HOST=0.0.0.0

database:
image: postgres
volumes:
- db_data:/var/lib/postgresql/data
env_file:
- .env/development/database

redis:
image: redis
volumes:
- redis_data:/data

selenium_chrome:
image: selenium/standalone-chrome-debug
logging:
driver: none
ports:
- “5900:5900”

volumes:
db_data:
labels:
- “myapp_db_data”
redis_data:
labels:
- “myapp_redis_data”

A server is already running error at this point can’t be solved by deleting tmp/pids/server.pid on the local machine because at this point, the server.pid file isn’t on the local environment.

This is because files generated by the container aren’t syncing onto the local environment at this point.

To get rid of the error, I had to remove the container. I began to see the server.pid file only after adding volume to the web service in the next section.

In the “Problem Starting Rails?” section at the end of the page, it’s written that “you’ve run into a bug with Compose”. This is not a bug with Compose, this is a Ralis-specific bug. please refer to Docker docs here docs.docker.com/compose/rails/#define-the-project

Apologies, this applies to various pages so I can’t provide a specific page number.

The final docker-compose.yml file contains two named services that include an underscore in them: webpack_dev_server and selenium_chrome. These are not valid hostnames and therefore I think they should be renamed either with dashes instead of underscores, i.e. webpack-dev-server and selenium-chrome, or without a separator, i.e. webpackdevserver and seleniumchrome. This would also need to be changed where the two hostnames are referenced as well.

This invalid format only caused me an issue when I upgraded to the 2.2.x version of rack in my latest Rails app. An improvement in rack has resulted in the gem strictly parsing hostnames and this broke my containers in a specific way: when I start the web container it is no longer able to connect with the webpack_dev_server, trying to connect on webpack_dev_server:3035:80 (note the appended default port, :80).

I’m not sure whether renaming services is the correct approach to solve the hostname error in a docker environment, particularly when running multiple containers for a service. Please advise whether there is a better solution to this invalid hostname problem. Thanks!

ERROR: Compiling Assets with Webpacker:

Issue: React “hello_react.jsx” not auto-updating.

Webpacker Log Excerpt:

2020-04-01 16:50:52 +0000: Rack app error handling request { GET /packs/js/application-d6267116cab8ac92bbc5.js }
#<SocketError: Failed to open TCP connection to webpack_dev_server:3035:80 (getaddrinfo: Name or service not known)>
/usr/local/lib/ruby/2.6.0/net/http.rb:949:in `rescue in block in connect’

INFO:

Rails version: 6.0.2.2
Ruby v2.6.5p114
webpack 4.42.1

ROOT CAUSE:

An improvement in rack has resulted in the gem strictly parsing hostnames and this broke my containers in a specific way: when I start the web container it is no longer able to connect with the webpack_dev_server [see above error]

SOLUTION:

\t1. Updated docker-compose.yml & ./config/webpacker.yml
\t2. $ docker-compose down —remove-orphans
\t3. $ docker-compose up -d web
\t4. $ docker-compose up -d redis
\t5. $ docker-compose up -d database

[docker-compose.yml]

version: ‘3’

services:
web:
build: .
ports:
- “3000:3000”
volumes:
- .:/usr/src/app
env_file:
- .env/development/web
- .env/development/database
environment:
- WEBPACKER_DEV_SERVER_HOST=webpackdevserver

webpackdevserver:
build: .
command: ./bin/webpack-dev-server
ports:
- 3035:3035
volumes:
- .:/usr/src/app
env_file:
- .env/development/web
- .env/development/database
environment:
- WEBPACKER_DEV_SERVER_HOST=0.0.0.0

redis:
image: redis

database:
image: postgres
env_file:
- .env/development/database
volumes:
- db_data:/var/lib/postgresql/data

volumes:
db_data:

[webpacker.yml]

development:
<<: *default
compile: true

# Verifies that correct packages and versions are installed by inspecting package.json, yarn.lock, and node_modules
check_yarn_integrity: true

# Reference: https://webpack.js.org/configuration/dev-server/
dev_server:
https: false
host: 0.0.0.0
port: 3035
public: 0.0.0.0:3035
hmr: false
# Inline should be set to true if using HMR
inline: true
overlay: true
compress: true
disable_host_check: true
use_local_ip: false
quiet: false
pretty: false
headers:
‘Access-Control-Allow-Origin’: ‘*’
watch_options:
ignored: ‘/node_modules/’

As of rack 2.2.2 hostnames with underscores are no longer valid. This means the webpack_dev_server service must be renamed to webpack-dev-server and references by the web service using WEBPACKER_DEV_SERVER_HOST=webpack-dev-server.

The caused error in the rails server logs looks like this:
SocketError: Failed to open TCP connection to webpack_dev_server:3035:80 (getaddrinfo: Name or service not known)

Rails comes with minitest as standard and some guidance for minitest users in how to setup selenim-chrome for system tests would have been nice. I don’t use RSpec (and have no wish to) and trying to convert your setup for RSpec into what I need for minitest has made this task more difficult than necessary.

There seem to be several issues related to Rails 6, Webpacker, and Yarn that would be worth clarifying. It took a lot of trial and error to get those pieces to work prior to the Redis chapter.

I can get yarn to install (thanks to a previous errata), and can add the Webpacker init command and yarn update in the right spots.

After that, I cannot get any ‘docker-compose up web’ command to work. The issue seems to be that mounting the local directory into the docker directory has some conflicts with init files.

I tried doing ‘rails webpacker:install’ in the local directory, this fails because the gems are now out of sync (since the local directory never ran bundle install).

I tried to ‘bundle install’ in the local directory, but then got errors about the yarn version out of sync and the server failed to start.

I also tried removing the yarn install and Webpacker install commands from the Dockerfile.

The only thing I can do to get this to run, is to remove the volume mount from the web service definition. (The copy is fine, but the mount seems to not work). I’m sure there is some slight discrepancy in the two setups, but I can’t resolve it at this point.

An answer to my previous issue where the rails server would not run saying ‘yarn packages are out of data’. I did manage to get it working with the local volume enabled.

docker-compose run —rm web bash
(from that shell)
rails s
(if you want, to confirm the issue and error message)
yarn install —check-files
exit

now docker-compose up -d web should run

There seems to be some incompatibility somewhere (node version, yarn version, exact node_modules loaded - not sure) that causes this. Running this command through the container shell, not local seems to put things in the right state for the container server to start. If you run ‘yarn install —check-files’ in the local shell, it gets messed up again and you have to repeat the above commands.

Rob Isenberg is dreadfully far behind other Docker authors on this one, it’s frustrating to read so many errata and still no sign of update.
Getting past chapter 2 is an ordeal at best and sincerely needs some reasonable action taking.

At the end of chapter 2, after following all steps to T, I get this error:

/usr/local/bundle/gems/webpacker-4.2.2/lib/webpacker/env.rb:30:in `available_environments’: undefined method `keys’ for false:FalseClass (NoMethodError)

Can anyone help please?

As shown, the Rails build includes webpacker in the Gemfile but this gem requires installation from the command line as well. (I assume this is addressed in the JavaScript chapter.) This prevents the Rails app from running. The following line in the Gemfile needs to be commented out before spinning up the Docker image:

gem ‘webpacker’, ‘~> 4.0’

In the section titled ‘Migrating the Database’, pdf page 516 says to download the ‘wait-for’ script into the Rails root folder. I used the script located at www.github.com/mrako/wait-for but it did not work. I was able to go in to the container and run the migration, but the db-migrator does not work as written.
It would be great to include the correct script in the book.

In the ‘db-migrator’ service’s command config, the 2nd and 3rd arguments need to be reversed like this:
command: [“./wait-for”, “database:5432”, “—timeout=300”, “—”, “bin/rails”, “db:migrate”]