Перевод двух статей: «о том, как коммитить измнения в docker образ» и «руководство по перемещению docker контейнеров» / хабр

Тестирование работы образов и возможные ошибки

Выполним остановку предыдущих контейнеров и создадим новые. При этом выполним миграции и соберем все статические файлы:

В файле ‘docker-compose.prod.yml’ мы прописали что nginx будет работать на 1337 порту. Проверим, что сервер отвечает:

Я могу открыть сайт с любого компьютера в локальной сети т.к. в файле ‘.env.prod’ прописано несколько хостов с которых может быть принято соединение:

Если у вас будет появляться ошибка с ‘ALLOWED_HOSTS’, то вы можете установить следующее значение разрешающее все подключения с любого адреса:

Один из способов проверки работы статических файлов — это открытие панель администрирования по адресу ‘http://localhost/admin/’. Фрагмент, помеченный цифрой 1, говорит об ошибке. Фрагмент под цифрой 2 — нормальная работа:

Нам нужно убедиться, что везде верно прописаны настройки для статических файлов и следующая команда, которая собирает такие файлы воедино, выполнена:

Эти файлы должны отображаться на обоих контейнерах т.к. они работают с одним томом:

Если файлов нет — возможно у вас проблемы с правами. Сравните файл Docker. Если нет таких папок, то с томом в файле docker-compose.prod.yml. Ошибка так же может быть в файле конфигурации nginx.conf или в файле setting.py Django.

Для проверки медиа файлов, которые будут загружаться через Django, вы можете создать пустой файл:

Далее выполнить к нему запрос:

Если вернется ошибка 404 — то стоит посмотреть на те же места, что в случае статических файлов.

Чаще всего помогает просмотр логов через докер:

В некоторых случаях стоит удалить том с базой, который создавался ранее.

Подготовка сервера

Выполним предварительные настройки, необходимые для корректной работы нашего сервера.

Установка Docker

Сам репозиторий является контейнеров Docker, поэтому для его запуска необходимо установить одноименный сервис.

Подробнее, об установке Docker на разные операционные системы семейства Linux читайте на странице Установка Docker на Linux.

Настройка брандмауэра

В официальной документации по настройке хранилища образов Docker приводится пример использования порта 5000. Именно его мы и будем открывать. Рассмотрим примеры использования разных утилит для настройки фаервола.

В вашей системе не обязательно будет использоваться брандмауэр. Например, он может быть настроен, чтобы пропускать все сетевые пакеты. В таком случае, настройка, рассмотренная в данном пункте не обязательна.

а) Iptables (как правило, используется в системах на базе deb или в старых RPM).

Чтобы открыть нужный нам порт, вводим команду:

iptables -I INPUT -p tcp —dport 5000 -j ACCEPT

Для сохранения правила используем утилиту iptables-persistent:

apt-get install iptables-persistent

netfilter-persistent save

б) firewalld (как правило, используется в, относительно, новых системах на базе RPM).

Вводим команду для открытия порта 5000:

firewall-cmd —permanent —add-port=5000/tcp

Для применения правила вводим:

firewall-cmd —reload

Что такое docker-compose

Как docker может управлять отдельно взятым контейнером, так docker-compose помогает управлять не просто одним, а всеми контейнерами, которые составляют распределенное приложение. Причём, не только контейнерами, но и сетями, подключёнными папками и всеми связанными с этим настройками.

Ведь даже чтобы запустить простое вэб-приложение, состоящее всего из двух контейнеров (например, «web» с контентом и «db» с данными), нужно как минимум:

создать новую (иначе контейнеры не будут видеть друг друга по именам),
запустить контейнер с данными, дать ему имя db и подключить к сети,
запустить контейнер с вэб-контентом, назвать его web, и тоже подключить к сети.

Можно создать скрипт для этого, но тот достаточно быстро выйдет из-под контроля: контейнеры будут добавляться, порядок запуска меняться, и т. п. К тому же нужно учитывать, что какие-то контейнеры нужно сначала собрать, а какие-то уже готовы, сеть может быть уже создана, а может еще и нет, какие-то контейнеры нужно запустить первыми (db), а остальные — потом (web), и т.д. Больше элементов — больше комбинаций.

С docker-compose можно описать приложение целиком: со всеми его контейнерами, Docker-файлами, сетями и зависимости, а compose уже сам разберется, что с этим делать и как запускать.

Child commands

Command	Description
docker attach	Attach local standard input, output, and error streams to a running container
docker build	Build an image from a Dockerfile
docker builder	Manage builds
docker checkpoint	Manage checkpoints
docker commit	Create a new image from a container’s changes
docker config	Manage Docker configs
docker container	Manage containers
docker context	Manage contexts
docker cp	Copy files/folders between a container and the local filesystem
docker create	Create a new container
docker diff	Inspect changes to files or directories on a container’s filesystem
docker events	Get real time events from the server
docker exec	Run a command in a running container
docker export	Export a container’s filesystem as a tar archive
docker history	Show the history of an image
docker image	Manage images
docker images	List images
docker import	Import the contents from a tarball to create a filesystem image
docker info	Display system-wide information
docker inspect	Return low-level information on Docker objects
docker kill	Kill one or more running containers
docker load	Load an image from a tar archive or STDIN
docker login	Log in to a Docker registry
docker logout	Log out from a Docker registry
docker logs	Fetch the logs of a container
docker manifest	Manage Docker image manifests and manifest lists
docker network	Manage networks
docker node	Manage Swarm nodes
docker pause	Pause all processes within one or more containers
docker plugin	Manage plugins
docker port	List port mappings or a specific mapping for the container
docker ps	List containers
docker pull	Pull an image or a repository from a registry
docker push	Push an image or a repository to a registry
docker rename	Rename a container
docker restart	Restart one or more containers
docker rm	Remove one or more containers
docker rmi	Remove one or more images
docker run	Run a command in a new container
docker save	Save one or more images to a tar archive (streamed to STDOUT by default)
docker search	Search the Docker Hub for images
docker secret	Manage Docker secrets
docker service	Manage services
docker stack	Manage Docker stacks
docker start	Start one or more stopped containers
docker stats	Display a live stream of container(s) resource usage statistics
docker stop	Stop one or more running containers
docker swarm	Manage Swarm
docker system	Manage Docker
docker tag	Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
docker top	Display the running processes of a container
docker trust	Manage trust on Docker images
docker unpause	Unpause all processes within one or more containers
docker update	Update configuration of one or more containers
docker version	Show the Docker version information
docker volume	Manage volumes
docker wait	Block until one or more containers stop, then print their exit codes

Автозагрузка контейнеров

Часто встречается ситуация, когда контейнеры останавливаются вследствие определенных факторов. Простейший пример – произошла перезагрузка сервера. Чтобы избавиться от необходимости вручную запускать их, можно настроить автозапуск контейнеров. Для этого следует создать текстовые файлы со специальным форматом для сервиса systemcmd. Рассмотрим пример их создания на примере контейнера my-db, введя в терминал команду:

cat /etc/systemd/system/my-db.service

В пустой файл необходимо добавить следующий код и сохранить его:

Description=MY DB (PG) docker container
Requires=docker.service
After=docker.service


Restart=always
ExecStart=/usr/bin/docker start -a my-db
ExecStop=/usr/bin/docker stop -t 2 my-db
TimeoutSec=30


WantedBy=multi-user.target

После этого остается перезапустить демон systemcmd и включить автозагрузку контейнера mydb, набрав в терминале поочередно команды:

systemctl daemon-reload

systemctl start my-db.service

systemctl enable my-db.service

Настройка локального проекта Django

Dockerfile

Добавим Dockerfile в корневой каталог вашего проекта Django со следующим содержимым:

Давайте подробнее рассмотрим этот Dockerfile.

Строка 1 выбирает образ: FROM python: 3 указывает Docker начать с образа python: 3. Часто встречается Alpine версия образа Python. Alpine Linux намного меньше, чем большинство базовых образов дистрибутива, и в целом приводит к более компактным образам.

Строка 2 устанавливает переменную среды PYTHONUNBUFFERED равной 1. Что это? Обычно, если у вас есть процесс, передающий данные в ваше приложение, терминал может буферизовать данные. Терминал хранит данные в буфере до тех пор, пока не будет достигнут предел размера или определенный символ (обычно новая строка или EOF). В этот момент он полностью сбрасывает весь кусок данных в ваше приложение. То же самое для выходных данных и данных об ошибках (stdout и stderr). Эта опция сообщает терминалу не использовать буферизацию.

Оставшийся набор инструкций в строках 3-7:

создает каталог /code на корневом уровне
копирует файл require.txt в него
устанавливает пакеты Python (в контейнере не требуется virtualenv в начале)
копирует в него полный каталог проекта

Итак, Dockerfile рассмотренный выше:

выбирает базовый образ
настраивает его так, чтобы мы могли запускать что-то поверх него, устанавливая необходимые пакеты и копируя код нашего проекта Django.

Причесали! Вопрос: Итак, как нам запустить этот контейнер?

Ответ: Мы будем использовать docker-compose.

Вопрос: Но контейнер выше работает только с Django. Разве нам не нужен контейнер для Postgres?

Ответ: Нам не нужно настраивать контейнер Postgres, поскольку Docker предоставляет образ Docker для Postgres, который мы можем просто запустить. Затем мы входим в него и настраиваем его так, как если бы он работал локально.

Вопрос: Должны ли мы написать сценарий оболочки и выполнить процесс Docker на нашей локальной машине для обоих контейнеров?

Ответ: Нет. Docker предоставляет docker-compose, а не полагается на сценарии оболочки.

docker-compose

Большим преимуществом файла docker-compose.yml является то, что он очень удобочитаемый.

Добавим этот файл docker-compose.yml в каталог Django проекта:

У нас есть две «службы», db и web.

Служба db запускает процесс Postgres внутри контейнера, который использует образ postgres.

POSTGRES_DB, POSTGRES_USER и POSTGRES_PASSWORD жестко закодированы в docker-compose.yml. Однако вы можете настроить их для использования переменных среды, используя файл .env или .envrc. Это ИМХО не стоит усилий, если вы делаете это только для локального тестирования.

web служба запускает процесс runserver manage.py внутри контейнера с именем django_web.

Инструкция сборки: сообщает Docker compose использовать Dockerfile, расположенный в этом же каталоге, для запуска web службы. Служба будет запущена внутри контейнера django_web. Документы по сборке здесь.

Команда запускает команду runserver в Django и выставляет ее на порту контейнера 8000.

Контейнерное имя — это пользовательское имя, которое вы можете добавить для ясности. Мы увидим его эффект, когда будем запускать вещи в следующем разделе.

Среда позволяет вам повторно использовать переменные окружения с хоста. Больше информации об управлении переменными среды для вашего проекта Django. В этом случае переменная окружения DATABASE_URL используется повторно.

Тома используются для «монтирования» путей к хостам. Основное использование в нашем контексте — это «поделиться» кодом на нашей машине с кодом в служебном контейнере django_web. Документы здесь.

В заключение:

Строки 18-19 сопоставляют порт 8000 хост-машины с портом контейнера 8000.
Строки 20-21 обеспечивают зависимость web контейнера от контейнера db.

Достаточно объяснений! Давайте начнем!

Команды для управления контейнерами

Со временем после работы с Docker на локальной машине соберется достаточное количество активных и неактивных контейнеров. Для просмотра запущенных контейнеров применяется команда:

docker ps

Система выведет примерные результаты:
В этой инструкции разбирался запуск двух контейнеров — с образов hello-world и ubuntu. Хотя сейчас они не активные, но уже расположены в системе. Для просмотра находящихся в системе контейнеров нужно запустить docker ps, добавив параметр -a:

docker ps -a

В терминале отобразится примерный вывод:

Для просмотра последних созданных контейнеров используется опция -l:

docker ps -l

Чтобы запустить остановленный контейнер, необходимо ввести docker start и далее указать идентификатор или имя контейнера. Так выглядит запуск контейнера 2c88170e5391:

docker start 2c88170e5391

Контейнер будет запущен и чтобы просмотреть его статус, используется команда docker ps:

Чтобы выключить активный контейнер, используется команда docker stop с последующим указанием его идентификатора или имени. Здесь уже потребуется воспользоваться именем, которое предоставил контейнеру Docker (peaceful_minsky):

docker stop peaceful_minsky

Также может потребоваться перезапустить контейнер, не отключая его. Это можно сделать командой:

docker stop 2c88170e5391 && docker start 2c88170e5391

или:

docker restart 2c88170e5391

Отдельного внимания заслуживает запуск контейнера docker compose. Так, после смены настроек в файле docker-compose.yml (например, проброс порта) изменения не выполнятся автоматически. Вдобавок, команда restart также не поможет и потребуется выполнить пересборку контейнера, применив для этого команду build. Другими словами, он будет заново создан. Выполнить операцию можно следующей командой:

docker-compose up -d --no-deps --build

После чего отобразится похожий вывод:

Потребуется пара секунд, чтобы перезапуск контейнера полностью завершился, хотя в действительности Docker осуществив намного больше операций. То есть, собрал новый образ, создал новый контейнер на его основе, остановил старый, запустил новый и удалил старый.

Когда контейнер уже не нужен для дальнейшей работы, его можно удалить, набрав в терминале docker rm с добавлением его имени или идентификатора. Для поиска этих данных, которые связаны с hello-world, вводится команда:

docker ps -a

После чего можно приступать к удалению контейнера.

docker rm hello/root_my-test_1

Чтобы осуществить запуск нового контейнера с присвоением ему имени, предусмотрена опция —name. Также можно воспользоваться опцией —rm, позволяющей создавать контейнер, который будет автоматически удален после его остановки. Более подробную информацию о данных и других параметрах можно получить после ввода docker run help.

Помимо указанных выше команд из существующих контейнеров можно создавать образы для создания новых. Об этом речь пойдет далее.

Предварительные требования

убедитесь, что компьютер работает Windows 10, обновлен до версии 2004, сборки 18362 или более поздней.
Установите WSL и настройте имя пользователя и пароль для дистрибутива Linux, работающего в WSL 2.
установите Visual Studio Code(необязательно). Это обеспечит лучшие возможности, включая возможность кодирования и отладки в удаленном контейнере DOCKER и подключения к дистрибутиву Linux.
установите Терминал Windows(необязательно). Это обеспечит лучшие возможности, включая возможность настройки и открытия нескольких терминалов в одном интерфейсе (включая Ubuntu, Debian, PowerShell, Azure CLI или то, что вы предпочитаете использовать).
Зарегистрируйте идентификатор DOCKER в DOCKER Hub(необязательно).

Примечание

WSL может запускать дистрибутивы в режиме WSL версии 1 или WSL 2. Это можно проверить, открыв PowerShell и введя: . Убедитесь, что дистрибутив настроен на использование WSL 2, введя: . Замените на имя дистрибутив (например, Ubuntu 18,04).

в WSL версии 1 из-за фундаментальных различий между Windows и Linux подсистема docker не смогла запуститься непосредственно внутри WSL, поэтому группа docker разработала альтернативное решение с использованием виртуальных машин Hyper-V и линукскит. Однако поскольку WSL 2 теперь работает в ядре Linux с полной емкостью системных вызовов, Docker можно полностью запустить в WSL 2. это означает, что контейнеры Linux могут работать изначально без эмуляции, что обеспечивает лучшую производительность и совместимость между средствами Windows и Linux.

Дополнение. Добавляем еще неограниченное кол-во хостов с проектами

Т.к. у меня несколько проектов, а настройки веб сервера одни и теже, то вот что я делаю чтобы запускать свои сайты на виртуальных доменах.

1. нужно добавить строчки в /etc/hosts на вашей машине mac (или windows — c:\windows\system32\drivers\etc\hosts), чтоб ваша операционная система понимала по какому адресу обращаться при запросе вашего хоста.

нажимаем ctrl + o, ctrl+x (перезаписываем и сохраняем файл)

2. добавляем в файл конфига /Users/your_name/Documents/docker/lamp/config/vhosts/default.conf
следующие строчки, он будет синхронизирован с контейнером Докер.

3. Чтобы наши изменения вступили в силу — перезапускаем контейнеры:

Репозиторий для localhost

Для начала мы развернем репозиторий, который сможет обслуживать только локальный сервер (о том, как развернуть сетевое хранилище образов Docker будет ).

Чтобы запустить сервис, который сможет принимать запросы docker push и docker pull, вводим команду:

docker run -d -p 5000:5000 —restart=always —name registry registry:2

* в данном примере мы поднимает контейнер Docker с именем registry из образа registry:2. Он будет слушать сетевые запросы на порту 5000. Параметр —restart=always позволит автоматически запускаться контейнеру после перезагрузки сервера.

Проверяем, что на порту 5000 у нас запустился контейнер docker:

ss -tunlp | grep :5000

Мы должны увидеть что-то на подобие:

tcp LISTEN 0 4096 *:5000 *:* users:((«docker-proxy»,pid=484238,fd=4))

Попробуем проверить работу нашего репозитория. На том же сервере сначала загрузим из облака докер-хаба образ, например, для python:

docker pull python:latest

Далее мы должны установить новый тег для образа, в начале названии которого должно идти указание на сервер и порт хранения образа:

docker tag python:latest localhost:5000/python

* в данном примере мы указываем тег localhost:5000/python, в названии которого мы видим localhost:5000 — локальный сервер, порт 5000.

Загружаем образ питона на наш сервер:

docker push localhost:5000/python

Теперь удалим тот образ, который был загружен из облака:

docker image remove python:latest

… и образ, который мы загрузили в наш локальный репозиторий:

docker image remove localhost:5000/python

Теперь снова загрузим образ python, но на этот раз из нашего собственного репозитория:

docker pull localhost:5000/python

Мы должны увидеть процесс загрузки:

Using default tag: latest
latest: Pulling from python
8bf9c589d5f9: Pull complete
4c70e46d8b5f: Pull complete
ea848ad42f0d: Pull complete
48fe137f8d26: Pull complete
4b13f6ed9b0c: Extracting 56.82MB/192.3MB
ba85279f50e0: Download complete
59a18d8c3680: Download complete
c610993f70c6: Download complete
a9afc028cd66: Download complete

Который должен завершиться загрузкой образа в систему:

Digest: sha256:1e3b89f69bb6ada672153256bd88d74ae60571f6755703369a108c76595ea00f
Status: Downloaded newer image for localhost:5000/python:latest
localhost:5000/python:latest

Наш репозиторий Docker готов и работает для локального сервера.

Что такое Docker

Docker представляет собой систему управления контейнерами. Она позволяет «упаковать» приложение или веб-сайт со всем его окружением и зависимостями в контейнер, которым в дальнейшем можно легко и просто управлять: переносить на другой сервер, масштабировать, обновлять.

Docker был написан на языке программирования Go и выпущен в 2013 году. Изначально он работал только с Linux-системами, однако на данный момент его можно использовать также в Windows и macOS. Несмотря на то, что проект является относительно новым, Докер широко используется многими специалистами и продолжает завоевывать популярность.

Важной частью экосистемы Docker является Docker Hub – открытый репозиторий образов контейнеров. В нем можно найти десятки готовых приложений от официальных разработчиков

Среди них – nginx, MySQL, Apache, Gitlab, Redmine, Elasticsearch, Jenkins и другие.

Например, для запуска WordPress с помощью Docker достаточно выполнить следующие команды:

docker run --name wp-mysql -e MYSQL_ROOT_PASSWORD=wpmsqlpsswd -d mysql:5.7
<вывод пропущен>
docker run --name my-wordpress --link wp-mysql:mysql -d -p 80:80 wordpress

После этого откройте в браузере страницу http://12.34.56.78 (здесь укажите реальный IP-адрес вашего VDS) и приступите к настройке CMS!

Теперь расскажем о том, что представляет собой Docker. Три основных термина в экосистеме Docker:

Образ (image) – шаблон, который используется для создания контейнеров. Представляет собой слепок файловой системы, в котором расположен код приложения и его окружение.
Реестр (registry) – репозиторий образов. Docker Hub, о котором шла речь выше, – это публичный репозиторий, где хранится огромное количество образов.
Контейнер (container) – запущенное приложение, т.е. совокупность процессов и образа.

Step 4: Build and run your app with Compose

From your project directory, start up your application by running .

Compose pulls a Redis image, builds an image for your code, and starts the
services you defined. In this case, the code is statically copied into the image at build time.
Enter http://localhost:5000/ in a browser to see the application running.

If you’re using Docker natively on Linux, Docker Desktop for Mac, or Docker Desktop for
Windows, then the web app should now be listening on port 5000 on your
Docker daemon host. Point your web browser to http://localhost:5000 to
find the message. If this doesn’t resolve, you can also try
http://127.0.0.1:5000.

If you’re using Docker Machine on a Mac or Windows, use to get the IP address of your Docker host. Then, open
in a browser.

You should see a message in your browser saying:
Refresh the page.

The number should increment.
Switch to another terminal window, and type to list local images.

Listing images at this point should return and .

You can inspect images with .
Stop the application, either by running
from within your project directory in the second terminal, or by
hitting CTRL+C in the original terminal where you started the app.

Extended description

The command builds Docker images from a Dockerfile and a
“context”. A build’s context is the set of files located in the specified
or . The build process can refer to any of the files in the
context. For example, your build can use a
instruction to reference a file in the context.

The parameter can refer to three kinds of resources: Git repositories,
pre-packaged tarball contexts and plain text files.

Git repositories

When the parameter points to the location of a Git repository, the
repository acts as the build context. The system recursively fetches the
repository and its submodules. The commit history is not preserved. A
repository is first pulled into a temporary directory on your local host. After
that succeeds, the directory is sent to the Docker daemon as the context.
Local copy gives you the ability to access private repositories using local
user credentials, VPN’s, and so forth.

Git URLs accept context configuration in their fragment section, separated by a
colon (). The first part represents the reference that Git will check out,
and can be either a branch, a tag, or a remote reference. The second part
represents a subdirectory inside the repository that will be used as a build
context.

For example, run this command to use a directory called in the branch
:

The following table represents all the valid suffixes with their build
contexts:

Build Syntax Suffix	Commit Used	Build Context Used

Tarball contexts

If you pass an URL to a remote tarball, the URL itself is sent to the daemon:

The download operation will be performed on the host the Docker daemon is
running on, which is not necessarily the same host from which the build command
is being issued. The Docker daemon will fetch and use it as the
build context. Tarball contexts must be tar archives conforming to the standard
UNIX format and can be compressed with any one of the ‘xz’, ‘bzip2’,
‘gzip’ or ‘identity’ (no compression) formats.

Text files

Instead of specifying a context, you can pass a single in the
or pipe the file in via . To pipe a from :

With Powershell on Windows, you can run:

If you use or specify a pointing to a plain text file, the system
places the contents into a file called , and any ,
option is ignored. In this scenario, there is no context.

By default the command will look for a at the root
of the build context. The , , option lets you specify the path to
an alternative file to use instead. This is useful in cases where the same set
of files are used for multiple builds. The path must be to a file within the
build context. If a relative path is specified then it is interpreted as
relative to the root of the context.

In most cases, it’s best to put each Dockerfile in an empty directory. Then,
add to that directory only the files needed for building the Dockerfile. To
increase the build’s performance, you can exclude files and directories by
adding a file to that directory as well. For information on
creating one, see the .

If the Docker client loses connection to the daemon, the build is canceled.
This happens if you interrupt the Docker client with or if the Docker
client is killed for any reason. If the build initiated a pull which is still
running at the time the build is cancelled, the pull is cancelled as well.

For example uses of this command, refer to the below.

Итого

В итоге я даже рад что случилось это изменение. Это меня сподвигло к тому чтобы уйти
от супервизора который мне и не нужен к запуску через docker-compose, который я
понимаю и могу контролировать.

Несколько часов на переезд и и меня опять все работает.
Даже, похоже, что это жрет немного меньше ресурсов (хотя это все неважно, раньше
проц был загружен на 4%, сейчас на 2%, все то же самое)

Я только-только это сделал, и пока не пожил с этим. Вполне возможно
что какие-то вещи я переделаю, но пока мне кажется очень верным решение
вообще отказаться от супервизора.

Пока я не понимаю, будет ли Home Assistant продолжать выпускать официальные
докер образы с системой. По моим ощущениям, должны, но я слышал
некоторые сомнения от разных людей. Но даже если они не будут
сами делать образы, придется самому заворачивать код в образ, что
вполне решаемо.

Иван Бессарабов[email protected]

10 мая 2020

Заключение

В этой статье мы рассмотрели, как создать контейнер для веб-приложения Django с Postgres. Мы также создали готовый к работе файл Docker Compose, который добавляет Gunicorn и Nginx в нашу конфигурацию для обработки статических и мультимедийных файлов. Теперь вы можете проверить производственную настройку локально.

С точки зрения фактического развертывания в производственной среде, вы, вероятно, захотите использовать:

Полностью управляемый сервис базы данных— такой как RDS или Cloud SQL — вместо того, чтобы управлять своим собственным экземпляром Postgres в контейнере.
Пользователь без полномочий root для и сервисов

Для других советов работы с производственной средой, см эту дисскусию.

Спасибо за чтение

Источники используемые для этой статьи

William Vincent — How to use Django, PostgreSQL, and Docker
Michael Herman — Dockerizing Django with Postgres, Gunicorn, and Nginx

Spread the love

1
Поделиться