Wordpress с помощью docker-compose.yml на CentOS - PullRequest
Новая
       15

Wordpress с помощью docker-compose.yml на CentOS

0 голосов
/ 03 июля 2019

Я впервые пробую Вультр с CentOS.

Мне удалось успешно разработать локальный веб-сайт Wordpress с пользовательской темой, теперь я пытаюсь развернуть его на сервере CentOS в Vultr. Мой docker-compose.yml выглядит так: 

version: '3.3'

services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:5.2.2-php7.1-apache
    ports:
      - "80:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    working_dir: /var/www/html
    volumes:
      - ./wp-content:/var/www/html/wp-content
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
volumes:
  db_data: {}

Как мне настроить изображения? Должен ли я создать три изображения для wordpress, mysql и wp-content & uploads.ini, ссылающихся на них в docker-compose? Или я могу сделать только одно изображение всего?

1 Ответ

0 голосов
/ 03 июля 2019

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

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

Фактически, вы можете поместить все вещи в один собственный образ и указать разные команды в образе для разных сервисов docker-compose. Э.Г. 

services:
  db:
    image: your_own_solo_image
    command: the command to start db

  wordpress:
    image: your_own_solo_image
    command: the command to start wordpress
    depends_on:
      - db

Недостаток использования одного изображения:

  • Может быть, одному контейнеру просто нужно небольшое базовое изображение, например, Alpine, другому контейнеру требуется Ubuntu, но с унифицированным образом (скажем, Ubuntu), когда два контейнера запускаются, все они будут использовать Ubuntu, возможно, некоторые дополнительные потери памяти, так как Ubuntu будет потреблять больше ресурсов по сравнению с Alpine.

  • Вы можете столкнуться с конфликтом библиотек, например, для container1 (service1) требуется lib.so.1, а для container2 (service2) может потребоваться lib.so.2, вам, возможно, придется самостоятельно обрабатывать LD_LIBRARY_PATH. Если вы разделяете изображения, здесь нет проблем.

Преимущество использования одного изображения:

  • Иногда вам может потребоваться разделить службу (команду) на разные контейнеры, но две команды действительно очень зависят от одного и того же исходного кода одного проекта, и среда все одинакова, поэтому нет необходимости использовать разные изображения для разных контейнеров ( другой сервис в сочинении). Одним из примеров является проект django, вы можете запустить wsgi в одном сервисе, но также можете запустить работника celery в другом сервисе, но при этом использовать тот же код вашего проекта django.
...