Используем django, postgresql и nginx в контейнерах docker

Подключение к базе из веб-сервера

По отдельности, наши серверы готовы к работе. Теперь настроим их таким образом, чтобы из веб-сервера можно было подключиться к СУБД.

Зайдем в контейнер с базой данных:

docker exec -it maria_db /bin/bash

Подключимся к mariadb:

:/# mysql -p

Создадим базу данных, если таковой еще нет:

> CREATE DATABASE docker_db DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

* в данном примере мы создаем базу docker_db.

Создаем пользователя для доступа к нашей базе данных:

> GRANT ALL PRIVILEGES ON docker_db.* TO ‘docker_db_user’@’%’ IDENTIFIED BY ‘docker_db_password’;

* и так, мы дали полные права на базу docker_db пользователю docker_db_user, который может подключаться от любого хоста (%). Пароль для данного пользователя — docker_db_password.

Отключаемся от СУБД:

> quit

Выходим из контейнера:

:/# exit

Теперь перезапустим наши контейнеры с новым параметром, который будет объединять наши контейнеры по внутренней сети.

Останавливаем работающие контейнеры и удаляем их:

docker stop maria_db web_server

docker rm maria_db web_server

Создаем docker-сеть:

docker network create net1

* мы создали сеть net1.

Создаем новые контейнеры из наших образов и добавляем опцию —net, которая указывает, какую сеть будет использовать контейнер:

docker run —name maria_db —net net1 -d -v mariadb:/var/lib/mysql mariadb

docker run —name web_server —net net1 -d -p 80:80 dmosk/webapp:v1

* указав опцию —net, наши контейнеры начинают видеть друг друга по своим именам, которые мы задаем опцией —name.

Готово. Для проверки соединения с базой данных в php мы можем использовать такой скрипт:

<?php
ini_set(«display_startup_errors», 1);
ini_set(«display_errors», 1);
ini_set(«html_errors», 1);
ini_set(«log_errors», 1);
error_reporting(E_ERROR | E_PARSE | E_WARNING);
$con = mysqli_connect(‘maria_db’, ‘docker_db_user’, ‘docker_db_password’, ‘docker_db’);
?>

* в данном примере мы подключаемся к базе docker_db на сервере maria_db с использованием учетной записи docker_db_user и паролем docker_db_password.

После его запуска, мы увидим либо пустой вывод (если подключение выполнено успешно), либо ошибку.

Этап 2. Добавляем пути к сертификатам

В добавляем

- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot

В добавляем

volumes:
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot

Результат

version: '3.7'

services:
  nginx:
    container_name: nginx
    image: nginx:latest
    networks:
      nginx_net:
    volumes:
      - ./data/nginx.conf:/etc/nginx/conf.d/default.conf
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    ports:
      - 80:80
      - 443:443
  certbot:
    container_name: certbot
    image: certbot/certbot
    networks:
      nginx_net:
    volumes:
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot

networks:
  nginx_net:
    name: nginx_net

SSL и подключение по сети

Репозиторий образов Docker не будет работать по сети и обслуживать другие узлы, если мы не зашифруем подключения. Для этого необходимо подключить сертификат безопасности к нашему контейнеру. Рассмотрим варианты его получения и запуска последнего с нужными опциями.

Получение сертификата

Есть 4 стандартных способа получения сертификата, которые нам подойдут. У каждого из них свои преимущества и недостатки.

1. Получение бесплатного сертификата у Let’s Encrypt.

Мы можем получить бесплатный легитимный сертификат от Let’s Encrypt. Для этого наш сервер должен быть доступен из внешней сети по порту 80 (для выполнения проверки домена) или мы должны перевыпускать сертификат вручную каждые 3 месяца. Подробнее о способах получения в инструкции Получение бесплатного SSL сертификата Let’s Encrypt.

2. Покупка.

Если мы хотим получить валидный сертификат, но при этом не можем обеспечить доступность сервера по 80 порту (или не хотим заниматься ручным обновлением сертификата каждые 3 месяца), мы можем купить сертификат. Поставщиков данной услуги, достаточно, много, например REG.RU.

3. Самоподписанный сертификат.

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

Чтобы создать такой сертификат, вводим команды:

mkdir -p /etc/ssl/docrepo

openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/docrepo/public.pem -keyout /etc/ssl/docrepo/private.key -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=docrepo.dmosk.local»

* первой командой мы создадим каталог, в котором разместим наши сертификаты. Второй — сам сертификат.

4. Использование внутреннего центра сертификации.

Мы также можем сгенерировать валидный для нашей внутренней инфраструктуры сертификат, используя свой центр сертификации. Подробнее читайте в инструкции Сертификат для Linux в центре сертификации Active Directory Certificate Services.

Запуск внешнего репозитория

После получения сертификата, можно поднять контейнер для обслуживания сетевых запросов. Предполагается, что наши сертификаты находятся в каталоге на сервере /etc/ssl/docrepo.

Сначала уничтожим ранее созданный:

docker container stop registry && docker container rm -v registry

И запустим новый:

docker run -d -p 5000:5000 —restart=always —name registry -v /dockerrepo:/var/lib/registry -v /etc/ssl/docrepo:/certs -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/public.pem -e REGISTRY_HTTP_TLS_KEY=/certs/private.key registry:2

* к нашей команде добавлены опции:

• -v /etc/ssl/docrepo:/certs — монтирует каталог на сервере /etc/ssl/docrepo (с сертификатами) в каталог контейнера /certs.
• -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/public.pem — создает системную переменную REGISTRY_HTTP_TLS_CERTIFICATE в контейнере, которая содержит в качестве значения путь до сертификата с открытым ключом.
• -e REGISTRY_HTTP_TLS_KEY=/certs/private.key — создает системную переменную REGISTRY_HTTP_TLS_KEY в контейнере, которая содержит в качестве значения путь до сертификата с закрытым ключом.

Подключаемся к другому компьютеру и пробуем загрузить наш образ для nginx:

docker pull docrepo.dmosk.local:5000/nginx

Если мы используем неподтвержденный сертификат (самоподписанный), то команда вернет нам ошибку:

Error response from daemon: Get https://docrepo.dmosk.local:5000/v2/: x509: certificate signed by unknown authority

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

vi /etc/docker/daemon.json

И добавляем к настройке:

{
    «insecure-registries» :
}

* где docrepo.dmosk.local:5000 — адрес и порт нашего сервера, к которому мы будем обращаться.

Перезапускаем сервис докера:

systemctl restart docker

Можно снова пробовать загрузить образ с центрального Hub-сервера.

Установка Docker

Рассмотрим примеры установки на базе операционных систем Red Hat/CentOS и Debian/Ubuntu.

Red Hat/CentOS

Устанавливаем репозиторий — для этого загружаем файл с настройками репозитория:

wget https://download.docker.com/linux/centos/docker-ce.repo

* если система вернет ошибку, устанавливаем wget командой yum install wget.

… и переносим его в каталог yum.repos.d:

mv docker-ce.repo /etc/yum.repos.d/

Устанавливаем docker:

yum install docker-ce docker-ce-cli containerd.io

Если система вернет ошибку Необходимо: container-selinux >= …, переходим на страницу пакетов CentOS, находим нужную версию container-selinux и копируем на него ссылку:

… с помощью данной ссылки выполняем установку:

yum install http://mirror.centos.org/centos/7/extras/x86_64/Packages/container-selinux-2.99-1.el7_6.noarch.rpm

После повторяем команду на установку докера:

yum install docker-ce docker-ce-cli containerd.io

В deb-системе ставится командой:

apt-get install docker docker.io

После установки

Разрешаем запуск сервиса docker:

systemctl enable docker

… и запускаем его:

systemctl start docker

После проверяем:

docker run hello-world

… мы должны увидеть:

…
Hello from Docker!
This message shows that your installation appears to be working correctly.
…

Deploying NGINX Plus with Docker

So far we have discussed Docker for NGINX Open Source, but you can also use it with the commercial product, NGINX Plus. The difference is you first need to create an NGINX Plus image, because as a commercial offering NGINX Plus is not available at Docker Hub. Fortunately, this is quite easy to do.

Creating a Docker Image of NGINX Plus

To generate an NGINX Plus image, first create a Dockerfile. The examples we provide here use Alpine Linux 3.14 and Debian 11 (Bullseye) as the base Docker images. Before you can create the NGINX Plus Docker image, you have to download your version of the nginx-repo.crt and nginx-repo.key files. NGINX Plus customers can find them at the customer portal; if you are doing a free trial of NGINX Plus, they were provided with your trial package. Copy the files to the directory where the Dockerfile is located (the Docker build context).

As with NGINX Open Source, by default the NGINX Plus access and error logs are linked to the Docker log collector. No volumes are specified, but you can add them if desired, or each Dockerfile can be used to create base images from which you can create new images with volumes specified, as described previously.

We purposely do not specify an NGINX Plus version in the sample Dockerfiles, so that you don’t have to edit the file when you update to a new release of NGINX Plus. We have, however, included commented versions of the relevant instructions for you to uncomment if you want to make the file version‑specific.

Similarly, we’ve included instructions (commented out) that install official dynamic modules for NGINX Plus.

By default, no files are copied from the Docker host as a container is created. You can add definitions to each Dockerfile, or the image you create can be used as the basis for another image as described above.

Creating the NGINX Plus Image

With the Dockerfile, nginx-repo.crt, and nginx-repo.key files in the same directory, run the following command there to create a Docker image called nginxplus (as before, note the final period):

The flag indicates that we are using Docker BuildKit to build the image, as required when including the option which is discussed below.

The option tells Docker to build the image from scratch and ensures the installation of the latest version of NGINX Plus. If the Dockerfile was previously used to build an image and you do not include the option, the new image uses the version of NGINX Plus from the Docker cache. (As noted, we purposely do not specify an NGINX Plus version in the Dockerfile so that the file does not need to change at every new release of NGINX Plus.) Omit the option if it’s acceptable to use the NGINX Plus version from the previously built image.

The option passes the certificate and key for your NGINX Plus license to the Docker build context without risking exposing the data or having the data persist between Docker build layers. The values of the arguments cannot be changed without altering the base Dockerfile, but you need to set the arguments to the path to your NGINX Plus certificate and key files (the same directory where you are building the Docker image if you followed the previous instructions).

Output like the following from the command indicates that the image was created successfully:

To create a container named mynginxplus based on this image, run this command:

You can control and manage NGINX Plus containers in the .

Этап 4. Завершаем настройку docker-compose.yml для nginx и certbot

В добавляем

restart: unless-stopped
# Перезапустит контейнер в непредвиденных ситуациях
command: '/bin/sh -c ''while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g "daemon off;"'''
# Перезапустит nginx контейнер каждые 6 часов и подгрузит новые сертификаты, если есть

В добавляем

restart: unless-stopped
entrypoint:  "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
# Проверяет каждые 12 часов, нужны ли новые сертификаты

Результат

version: '3.7'

services:
  nginx:
    container_name: nginx
    image: nginx:latest
    restart: unless-stopped
    networks:
      nginx_net:
    volumes:
      - ./data/nginx.conf:/etc/nginx/conf.d/default.conf
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    ports:
      - 80:80
      - 443:443
    command: '/bin/sh -c ''while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g "daemon off;"'''

  certbot:
    container_name: certbot
    image: certbot/certbot
    restart: unless-stopped #+++
    networks:
      nginx_net:
    volumes:
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

networks:
  nginx_net:
    name: nginx_net

Шаг 4 — Создание файла Dockerfile

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

Файл будет располагаться в каталоге . Создайте файл:

Этот файл будет задавать базовый образ и необходимые команды и инструкции для построения образа приложения Laravel. Добавьте в файл следующий код:

~/laravel-app/php/Dockerfile

Сначала Dockerfile создает образ поверх образа Docker. Это образ на базе с установленным экземпляром PHP FastCGI PHP-FPM. Также этот файл устанавливает требуемые пакеты для Laravel: , , и с .

Директива задает команды для обновления, установки и настройки параметров внутри контейнера, включая выделенного пользователя и группу с именем www. Инструкция задает каталог как рабочий каталог приложения.

Создание отдельного пользователя и группы с ограниченными правами доступа снижает уязвимость при запуске контейнеров Docker, которые по умолчанию запускаются с привилегиями root. Вместо запуска этого контейнера с привилегиями root мы создали пользователя www с правами чтения и записи для папки с помощью команды с флагом для копирования разрешений папки приложения.

Команда открывает порт в контейнере для сервера . указывает команду, которая должна запускаться после создания контейнера. Здесь указывает команду , которая запускает сервер.

Когда закончите вносить изменения, сохраните файл и закройте редактор.

Теперь вы можете перейти к определению конфигурации PHP.

Running NGINX Plus in a Docker Container

Docker can also be used with NGINX Plus. The difference between using Docker with NGINX Open Source is that you first need to create an NGINX Plus image, because as a commercial offering NGINX Plus is not available at Docker Hub.

Creating NGINX Plus Docker Image

To generate an NGINX Plus image:

1. Create the Docker build context, or a Dockerfile:

2. As with NGINX Open Source, default NGINX Plus image has the same default settings:

   • access and error logs are linked to the Docker log collector
   • no volumes are specified: a Dockerfile can be used to create base images from which you can create new images with volumes specified, or volumes can be specified manually:

   no files are copied from the Docker host as a container is created: you can add COPY definitions to each Dockerfile, or the image you create can be used as the basis for another image

3. Log in to MyF5 Customer Portal and download your nginx-repo.crt and nginx-repo.key files. For a trial of NGINX Plus, the files are provided with your trial package.

4. Copy the files to the directory where the Dockerfile is located.

5. Create a Docker image, for example, (note the final period in the command).

   The option tells Docker to build the image from scratch and ensures the installation of the latest version of NGINX Plus. If the Dockerfile was previously used to build an image without the option, the new image uses the version of NGINX Plus from the previously built image from the Docker cache.

   

   

   

   

   

   

   

   

   

   

6. Verify that the image was created successfully with the command:

7. Create a container based on this image, for example, container:

8. Verify that the container is up and running with the command:

NGINX Plus containers are controlled and managed in the same way as NGINX Open Source containers.

Описание инструкций Dockerfile

Инструкция	Описание	Пример
FROM	Указывает, какой базовый образ нужно использовать. Обязательная инструкция для Dockerfile	FROM ubuntu:16.04
MAINTAINER	Автор образа.	MAINTAINER DMosk <[email protected]>
RUN	Выполняет команду в новом слое при построении образа.	RUN apt-get install python
CMD	Запускает команду каждый раз при запуске контейнера. Может быть вызвана только один раз. Если в Dockerfile указать несколько таких инструкций, то выполнена будет последняя.	CMD
LABEL	Добавляет метаданные.	LABEL version=»2″
EXPOSE	Указывает, какой порт должно использовать приложение внутри контейнера.	EXPOSE 8080
ENV	Задает переменные окружения в образе.	ENV PGPASSWORD pass
ADD	Добавляет файлы/папки из текущего окружения в образ. Если в качестве копируемого файла указать архив, то он будет добавлен в образ в распакованном виде. Также в качестве источника принимает URL.	ADD /root/.ssh/{id_rsa,id_rsa.pub} /root/.ssh/
COPY	Также как и ADD добавляет файлы в образ, но обладает меньшими функциями — не принимает URL и не распаковывает архивы. Рекомендован для использования в случаях, где не требуются возможности ADD или когда нужно перенести архив, как архив.	COPY ./mypasswd /root/
ENTRYPOINT	Указывает команду, которой будет передаваться параметр при запуске контейнера.	ENTRYPOINT [«/sbin/apache2»]
VOLUME	Добавляет том в контейнер.	VOLUME [«/opt/myapp»]
USER	Задает пользователя, от которого будет запущен образ.	USER user:group
WORKDIR	Можно задать каталог, откуда будут запускаться команды ENTRYPOINT и CMD.	WORKDIR /opt/apps
ARG	Создает переменную, которую может использовать сборщик.	ARG folder=/opt/apps WORKDIR $folder
ONBUILD	Действия, которые выполняются, если наш образ используется как базовый для другой сборки.	ONBUILD ADD . /app/src
STOPSIGNAL	Переопределяет сигнал SIGTERM для завершения контейнера.	STOPSIGNAL SIGINT
HEALTHCHECK	Команда, которая будет проверять работоспособность контейнера.	HEALTHCHECK —interval=5m —timeout=3s CMD curl -f http://localhost/ || exit 1
SHELL	Позволяет заменить стандартную оболочку для выполнения команд на пользовательскую.	SHELL [«/bin/sh», «-c»]

Создание новой страницы «О нас» в Django

Процесс добавления страницы «О нас» очень похож на то, что мы только что сделали. Создадим новый файл шаблона, новое представление, а также новый адрес URL.

Закрываем веб-сервер через комбинацию и создаем новый шаблон под названием .

Shell

(pages) $ touch templates/about.html

1	(pages)$touchtemplatesabout.html

Затем добавляем короткий HTML заголовок.

Python

<!— templates/about.html —>
<h1>About page</h1>

1 2	<!—templatesabout.html—> <h1>About page<h1>

Создаем новое представление для страницы.

Python

# pages/views.py
from django.views.generic import TemplateView

class HomePageView(TemplateView):
template_name = ‘home.html’

class AboutPageView(TemplateView): # новое
template_name = ‘about.html’

1 2 3 4 5 6 7 8

# pages/views.py fromdjango.views.generic importTemplateView classHomePageView(TemplateView) template_name=’home.html’ classAboutPageView(TemplateView)# новое template_name=’about.html’

Далее связываем его с URL в .

Python

# pages/urls.py
from django.urls import path

from .views import HomePageView, AboutPageView # новое

urlpatterns = [
path(‘about/’, AboutPageView.as_view(), name=’about’), # новое
path(», HomePageView.as_view(), name=’home’),
]

1 2 3 4 5 6 7 8 9

# pages/urls.py fromdjango.urls importpath from.views importHomePageView,AboutPageView# новое urlpatterns= path(‘about/’,AboutPageView.as_view(),name=’about’),# новое path(»,HomePageView.as_view(),name=’home’),

Запускаем сервер при помощи .

В браузере переходим по адресу . У вас должна появиться новая страница — «About page».

Страница «О Нас»

MariaDB

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

Сначала создаем том для докера:

docker volume create —name mariadb

* в данном примере мы создали том с именем mariadb. Будет создан каталог /var/lib/docker/volumes/mariadb/_data/ на хостовом сервере, куда будут размещаться наши файлы базы.

Выполним первый запуск нашего контейнера с mariadb:

docker run —rm —name maria_db -d -e MYSQL_ROOT_PASSWORD=password -v mariadb:/var/lib/mysql mariadb

* где:

• —rm — удалить контейнер после остановки. Это первый запуск для инициализации базы, после параметры запуска контейнера будут другими.
• —name maria_db — задаем имя контейнеру, по которому будем к нему обращаться.
• -e MYSQL_ROOT_PASSWORD=password — создаем системную переменную, содержащую пароль для пользователя root базы данных. Оставляем его таким, как в данной инструкции, так как следующим шагом мы его будем менять.
• -v mariadb:/var/lib/mysql — говорим, что для контейнера мы хотим использовать том mariadb, который будет примонтирован внутри контейнера по пути /var/lib/mysql.
• mariadb — в самом конце мы указываем имя образа, который нужно использовать для запуска контейнера. Это образ, который при первом запуске будет скачан с DockerHub.

В каталоге тома должны появиться файлы базы данных. В этом можно убедиться командой:

ls /var/lib/docker/volumes/mariadb/_data/

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

docker exec -it maria_db /bin/bash

Подключаемся к mariadb:

:/# mysql -ppassword

Меняем пароль для учетной записи root:

> SET PASSWORD FOR ‘root’@’localhost’ = PASSWORD(‘New_Password’);

Выходим из командной строки СУБД:

> quit

Выходим из контейнера:

:/# exit

Останавливаем сам контейнер — он нам больше не нужен с данными параметрами запуска:

docker stop maria_db

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

docker run —name maria_db -d -v mariadb:/var/lib/mysql mariadb

Сервер баз данных готов к работе.

Nginx

Nginx будет работать со статическими файлами и будет обращаться к Gunicorn. Первое, что мы сделаем — добавим следующие строки в файл ‘docker-compose.prod.yml’:

В примере выше мы открываем порт 1337 для посетителей сайта, который будет перенаправлять пакеты на 80 порт nginx. Вы можете изменить порт 1337 на любой другой.

Создадим папку, в которой будут хранится конфигурационный файл nginx и файл Docker:

Создадим файл конфигурации Nginx со следующим содержимым:

Что бы файл конфигурации попал в контейнер мы должны создать отдельный Dockerfile:

После создания образа Nginx мы уже не будем обращаться к Django напрямую, а это значит что мы можем закрыть для него доступ через перенаправление портов. Мы можем разрешить обращаться к Django только сервисам Docker. Для этого заменим ‘port’ на ‘expose’:

Запустим контейнеры еще раз и убедимся, что они работают:

Теперь у нас будет отвечать не Django, а nginx:

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

Репозиторий для 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 готов и работает для локального сервера.

(Optional) Step 7 — Using Your Own Nginx Configuration File

This section is for advanced users who want to use their own Nginx config file with their Nginx container. Please skip this step if you don’t have a custom config file you want to use.

Let’s go back a directory so we aren’t writing to our public HTML directory:

If you’d like to take a look at the default config file, just copy it using the Docker copy command:

Since we’re going to be using a custom file for Nginx, we will need to rebuild the container.

First stop the container:

Remove it with:

Now you can edit the default file locally (to serve a new directory, or to use a to forward the traffic to another app/container like you would with a regular Nginx installation). You can read about Nginx’s configuration file in our Nginx config file guide.

Once you’ve saved your custom config file, it’s time to make the Nginx container. Simply add a second flag with the appropriate paths to give a fresh Nginx container the appropriate links to run from your own config file.

This command also still links in the custom website pages to the container.

Please note that you will need to restart the container using a command if you make any changes to your config file after starting the container, since Nginx does not hot reload if its config file is changed:

nginx.conf

Чтобы наш сервер знал, как и с чем ему работать — нужно задать для него конфигурацию. Общая схема такая: на наш сервер на порт 80 приходит запрос, мы его проксируем на 80 порт контейнера с ngnix, он смотрит, если запрос на статику и медиа — отдает сам, а если запрос на логику — переадресовывает на контейнер с приложением на порт 8000. Приступим:

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

Дальше стандартный раздел server:

Слушаем 80 порт, если запрос пришел на главную страницу и все остальные, кроме статики и медиа, отправляем на наш контейнер django:8000, используя красивый upsteam-ярлык для этого djangodocker. Остальные строки просто передают также дальше и заголовки запросов.

Обратите внимание на команды root- Это означает, что /static/ приклеится к пути /code/ и станет /code/static

Команда alias в свою очередь указывает сразу на конечное расположение. Маленькая хитрость, лучше знать.