How to properly deploy using docker registry?

Question

Software Deployment

Hello,
There is a Rails project that now needs to be raised on a server in the nginx + puma bundle, or rather, I have already raised it, I did everything using docker. A separate container for nginx and a container for the staging and production branches of my rails application. The database is running on a separate server and also in a docker container. All this was lifted and collected for the first time. those. this is my first experience with docker. I decided to start setting up the deployment, by this time I had already picked up vertices and was sure that the docker was just great for deployment. As a first step, I set up my docker-registry, pushed into it from the dev-machine, and on the hosting from the production directory, respectively, did a pull. Here the registry did not work quite as I expected, I thought that, like git, it would expand the entire project structure inside the directory in which I made the pool, but it just pulled the image.docker run , but for some reason the dev version of the project started.
It was in brief, now I will try to accompany all of the above with configs and commands. :)
I use docker-compose because I didn’t like to fence huge docker commands with a bunch of parameters, my docker-compose.yml looks something like this:

version: '2'
services:
  development:
    container_name: app_dev
    build: .
    expose:
      - "3000"
    network_mode: host
    environment:
      PORT: 3000
      RACK_ENV: development
      RAILS_ENV: development
      DATABASE_URL: 'localhost:27017'

  production:
    container_name: app_prod
    image: app_prod
    build:
      context: .
      dockerfile: Dockerfile-prod
    restart: always
    env_file: prod.env
    ports:
      - '8080:8080'
    volumes:
      - /puma
      - /puma/log
      - /puma/pids
  staging:
    ...

I use the image parameter to add an image to the registry, if I understood everything correctly, then this is an analogue of the (-t) tag, like:

docker build -t app_prod.

Correct me if this is not the case. In general, while I was learning the whole thing, for the last two weeks, in addition to the documentation, I read all sorts of tutorials where it was advised to create docker-compose.yml for each env and then run something like this:

docker-compose -f docker-compose.prod.yml build/up

It seemed to me unreasonable, so I described all the env in one config, and then conveniently launched what I needed:

docker-compose up production

I think it's beautiful, everything worked on the local machine. It worked on the host too (before I tried to work with the registry). With the registry, the algorithm of my actions was something like this:

1. I watch "docker ps", I see a running container, whose name and image are equal to app_prod
   
2. docker tag app_prod my_registry:5000/app_prod:latest
   
3. docker push my_registry:5000/app_prod:latest - push passes
   
4. I go to the server, I go to the directory prepared for production
   
5. docker pull my_registry:5000/app_prod:latest - pool runs successfully
   
6. I do ls - I'm surprised that the directory is empty (as I wrote above, I expected it to be similar to git-pull)
   
7. there can be no talk of any convenient "docker-compose up production".
   
8. I try to do "docker run app_prod" - the project starts but in dev mode, I can't start production.
   

Here is probably the complete list of my stupidity in docker :). Help me figure out my mistakes, guide me on the right path :). The official documentation doesn't work for me. It is especially not clear how using composer it is normal to form an image and send it to regitry.
After the experience described above, I rethought the algorithm a little, but apparently it’s still not true. Right now I'm expecting something like this:

1. when i do "docker-compose up production" i start app_prod container
   
2. then with the command "tag app_prod" I create an image based on the container
   
3. and "push" actually sends the image to my registry server
   
4. I do "pull" on the server and get an image that can be started (start), which does not need to be assembled and configured, something like "compiled", but damn "start" does not work, but "run" seems to do it internally "build + start", i.e. rebuilds something.
   

There is no head, only porridge. Save! :)

Answer 1

The official documentation should still be read, showing perseverance. Then there will be no confusion in the basic concepts, because of which there is a mess in the head.
Let's look at the tools and their purpose that you use:
The team dockerdoes not juggle files, it juggles images and containers, and they are abstracted from us by Docker as something ephemeral. That is docker pull, when executing a command, you do not download the image to the folder where you execute the command, and certainly do not download any files. All you do with this command is download the image to your local Docker store so that the Docker daemon can run a container based on that image.
The team docker-composeis a completely different team. All it does is read the specified YAML manifest and execute the appropriate Docker commands. It just allows you to declaratively specify the desired scripts when working with Docker in a convenient format. But neither the team dockernordocker-compose, don't provide anything for transporting/updating versions of your manifests somewhere. Docker, again, juggles images and containers, nothing more.
You have a directive in your manifest build:. So it docker-composetries to build the container first, instead of just running it from the image.
Regarding advicedocker-compose.ymlunder each env, all correctly advised. That is exactly how it was intended. You specify in the manifest not different environments (development, production), but a set of containers that should run in one bundle as one logical unit (the concept of PODs). Nothing forbids doing the way you did, but it’s akin to using a colander as a bowl for food: today you normally wrap dumplings out of it, and tomorrow the soup in it is already leaking somewhere in the wrong place.
Workflow in your case can be organized as follows:
Bonus tip:
It's often convenient to automate building an image and uploading it to a remote registry using Makefiles.