AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

AWS_DEFAULT_REGION

INTERNAL_IP

IP_PORT

SWARM_TOKEN

BUCKET

DIGITAL_OCEAN_TOKEN

Gain insights into Docker architecture, images, and containers. Delve into Docker Compose, JS integration, and production readiness. Master deploying, clustering, and scaling Rails apps using Docker tools.

tarball.tar.gz

simpleJob

simpleJob2

simpleJob-copy

viewImages

dockerCompose1

challenge1

dockerComposeRedis1

dockerComposeRedis2

dockerComposeRedis3

cdToUsercode

delGitCopyUpCreate

delGitCopyUp

delGitCopyUpMigrate

webPackerCh7

RSpec-Ch8

RSpec-Ch8_2

RSpec-Ch8_2_1

RSpec-Ch8_3

runRailsUsingCustomImage

dockerCompose1-copy

RSpec-Ch8_2-copy

delGitCopyUp-copy

RSpec-Ch8_5

RSpec-Ch8_6

RSpec-Ch8_6_GUI

dockerCompose1-copy-copy

dockerComposePostgres1

webPackerCh7-copy

postgress_last_lesson

Ch12_2

postgress_2nd_last_lesson

Ch12_3

gem_1

gem_2

irritation_1

irritation_1_1

Ch12_1

webPackerCh7_2

Cloud

Cloud_DO

Cloud_1

Cloud_2_1

Cloud_2_2

Cloud_2_4

RSpec-Ch8_2_new

RSpec-Ch8_7

Cloud_1_1_bucket

dockerComposeRedis3-copy

dockerComposeRedis2-copy

Cloud_DO_2

chap4_1

chap5_3

chap5_4

challenge

simpleJob2-ForceRelaunch

simpleJob-ForceRelaunch

RSpec-Ch8_5-copy

dockerCompose1-copy-copy-copy

testing

chap4_1-copy

chap5_3-copy

chap5_4-copy

dockerComposeRedis3-copy-iwrz0a

postgress_2nd_last_lesson-copy

postgress_last_lesson-copy

webPackerCh7_2-copy

This course is your field manual for building Rails applications with Docker. 

To kick things off, you’ll start by learning the basics of Docker like architecture, images, and containers. You will then be introduced to Docker Compose and use it to build up to a multiservice application with Redis.

You will then work to get your Dockerized setup to play nice with JavaScript, using both the standard asset pipeline and webpacker, Rails’ newest approach for integrating modern JavaScript front ends.

Lastly, you will learn how to prepare your Rails app for production. Once ready, using Docker’s own tools, you will provision machines, create a cluster, deploy the app, and scale the app’s resources to meet its changing needs.

By the end of the course, you will be able to confidently use Docker in any of your further projects.

Docker for Rails Developers

# How can containers talk to each other? 
If two containers are isolated, independent processes, how are they able to talk to one another? 

While it is true that the code and processes running in a container are sandboxed, that does not mean the container has no way to communicate with the outside world. If containers could not communicate, we would not be able to connect them together to create a powerful, connected system of services that together make up our application. 

# Networks list 

The `docker-compose up` creates a new network for the app. By default, all containers for our app are connected to the app’s network and can communicate with each other. This means that our containers, just like a physical or virtual server, can communicate outside themselves using TCP/IP networking. 

We listed our currently defined networks using the following command: 
```text
$ docker network ls 
```
You should have seen some output similar to the following:
```text 
NETWORK ID NAME DRIVER SCOPE 
128925dfad81 bridge bridge local 
5bd7167263e8 host host local 
e2af02026928 usercode_default bridge local 
d1145155d62a none null local 
```
## Networks explanation
The first network called **bridge** is a legacy network to provide backward compatibility with some older Docker features. We will not be using it now that we have switched to Compose. Similarly, the **host** and **none** networks are special networks that Docker sets up that we do not need to worry about. 

The network we do care about is called **`usercode_default`**. This is our app’s dedicated network that Compose created for us. The reason Compose creates this network for us is simple: it knows that the services we are defining are all related to the same application, so inevitably they are going to need to talk to one another. 

# How do containers on `usercode_default` find each other?

All Docker networks (except for the legacy bridge network) have built-in **Domain Name System (DNS)** name resolution. That means that we can communicate with other containers running on the same network by name. Compose uses the service name (as defined in our `docker-compose.yml`) as the DNS entry. So if we wanted to reach our `web` service, it would be accessible via the hostname `web`. This provides a basic form of service discovery: a consistent way of finding container-based services, even across container restarts. 

This explains how we were able to connect from the Adhoc container running the `redis-cli` to our Redis server running as the `redis` service. Here is the command we used: 
```text
$ docker-compose run --rm redis redis-cli -h redis
``` 
The option `-h` `redis` says, “Connect to the host named `redis`.” This only worked because Compose had already created our app’s network and set up DNS entries for each service. In particular, our `redis` service can be referred to by the hostname `redis`.

In this lesson, we will see how communication happens between containers.

Learning How Containers Communicate

Introduction

A Brave New World

Running a Rails App in a Container

Fine-Tuning Our Rails Image

Describing Our App Declaratively with Docker Compose

Beyond the App: Adding Redis

Docker for Rails Developer—Exam 1

Adding a Database: Postgres

Playing Nice with JavaScript

Testing in a Dockerized Environment

Advanced Gem Management

Some Minor Irritations

Docker for Rails Developer—Exam 2

The Production Landscape

Preparing for Production

A Production-Like Playground

Deploying to the Cloud

Docker for Rails Developer - Exam 3

Closing Thoughts and Next Steps

APPENDIX

Learning How Containers Communicate

How can containers talk to each other?