Комментарии 22
Спасибо за статью.
Не могли бы Вы добавить пару слов о безопасности в докере (attack surface)? Тема важная в наши дни, и обычно про нее забывают. Ну и пару слов о том, как докер работает с сетями и какие они бывают (хотя конечно это тема для отдельной статьи).
Все круто, но идея управять контейнерами через systemd кажется странной. Можно ведь поставить `restart: unless-stopped`, зачем для этого systemd? Или в Podman это не сработает?
Для меня главное практическое преимущество – возможность не думать лишний раз. На каждом из десятков и сотен серверов есть удобный механизм – systemd юниты, который управляет зависимостями, заботится о восстановлении при сбоях, позволяет смотреть конфигурации и управлять всем необходимым ПО единообразно. В целом, думаю, можно обойтись и без systemd, особенно в небольших средах и проектах – дело вкуса
Простой пример. Есть сайт на пхп, использует мускуль и мемкеш. И все это живет в своей сети. У меня юниты системд имеют зависимости. Все юниты требуют наличия сети и триггерят её создание. Сам пхпфпм имеет в зависимостях юниты контейнеров мускуля и мемкеша. Т.е. я могу просто запустить пхпфпм и он автоматически запустит юниты контейнеров мускуля и мемкеша, которые в свою очередь запустят создание сети, если она не создана. Ну и плюс логи каждого контейнера пишутся в journald. бОльшую часть задач может решить podman/docker compose... Но для автоматического запуска всего, при возможном ребуте системы, его все равно нужно будет допиливать напильником. Да и какой же сайт без крон задач? Тут вообще на помощь прийдёт systemd и timers :)
Для локальной разработки,да, использую podman/docker compose.
Для автоматического запуска всего при старте системы в нужном порядке и с созданием виртуальной сети можно использовать docker-compose. И контейнеры могут являться единым способом управления ворклоадом, при чем, удобно то что они не смешиваются с системными делами, и всегда можно посмотреть чистый список запущенного. Зашёл на сервер, позвал "docker ps" и все узнал про него. Логироввние ликера можно настроить так чтобы оно использовало journald, но это не обязательно, так как всегда есть "docker logs". Мне до сих пор не понятно зачем использовать возможности хост-системы (которых может и не быть в systemd-less системах) для управления контейнерами, если контейнеры и сами отлично справляются. Если что-то на холсте работает без докера, то конечно systemd-units это единственный адекватный вариант управления жизненными циклом, но docker совершенно точно обладает достаточным функционалом чтобы его заменить.
А для десятков серверов с десятками контейнеров этот подход с локальным докером в принципе не походит, тут уже оркестратор нужен. Это же три независимых подхода: systemd (+Ansible?) -> docker/podman (+ docker-compose) -> K8s/Nomad... Каждый из них полностью спмостоятельно позволяет управлять жизненным циклом ворклоада.
Так я и не говорю, что системд панацея. Я для себя так сделал и привел пример, что можно вот так. опять же, подман редхатовский, что говорит о том, что там будет системд. Для запуска разных контейнеров, не связанных между собой, системд тоже вполне себе подойдет. для более серьезных архитектур уже можно смотреть и в сторону кубера, но там свои нюансы и цены.
Спасибо за статью, но никак не могу решиться изучать докер или нет, вроде бы нужно но и непонятно справится ли он с моей задачей лучше чем справляется проксмокс?
Есть сервер с несколькими контейнерами на проксмосе, веб сервер, сервер бд. На вебсервере несколько сайтов крутятся на nginx+php-fpm, есть желание разделить это все на несколько контейнеров, каждый сайт в своем контейнере с php-fpm, мускул и постгрес на отдельных контейнерах, в отдельном контейнере nginx. Ну и контейнеры отдельные для разработки. Вот стоит у меня вопрос, что будет эффективней, разделить это все в проксмосе, или изучить докер и реализовать на нем.
Может я вообще неправильно все понял. Прошу совета.
It may vary.
Если у вас кластер проксов и поднято HA, и вы не знаете как правильно сделать HA средствами самой БД — то не стоит.
Если же просто один хост, то нет принципиальной разницы, как все контейнеризировать. В докере слои, в проксе — container templates. В докере все изменения умирают, если не озаботиться их сохранением, lxc в проксе гораздо ближе к классике. Докер сам управляет файрволлом (через директивы в Dockerfile), прокс надо заставлять что-то делать через WebUI/API. Прокс умеет в снепшоты.
Еще можно поднять докер в контейнере прокса, выставив keyctl=1 и nesting=1, да посмотреть, как оно будет.
Есть у меня несколько персональных проектов, небольшие заказы сайтов, пару форумов и т.д. Всего штук 20 сайтов. Некоторые PHP, некоторые Python.
Вот все эти сайты у меня и работают — каждый в своём контейнере.
В каждом контейнере можно ставить нужную версию PHP, набор модулей и т.д.
Load Balancer для всего этого — Traefik.
Логи собираю FileBeat и отсылаю на Elastic.
База данных — mysql, одна на всех, установленная на хосте через apt install. Мне показалось, что базу надёжней будет поставить так, а не в докере, и по ресурсам лучше одну на всех. DB умеет нормально изолировать пользователей друг от друга.
Из минусов только то, что обновлять всё это хозяйство тяжелей.
Раньше было apt update; apt upgrade.
А теперь надо смотреть за контейнерами, некоторые из которых своей сборки.
Обновление хорошо решается через ci-cd процессы того же gitlab\github. Правда придется немного изучить Ansible (ну или что-нибудь альтернативное, по вкусу).
Тогда все обновление сведется к MRу в ветку prod.
Здравствуйте, можете подсказать по вопросам:
Веб-сервера в отдельных контейнерах?
Проброс портов как решается?
Используется что-то типа nginx-proxy или всё средствами Traefik?
Используется ли ssl?
— Nginx + php-fpm
— Apache + mod_php
— или просто уже готовые наборы, например «phpmyadmin/phpmyadmin»
Кто-то скажет, что это не докер-вэй — пихать в один контейнер несколько сервисов, и Nginx должен быть в отдельном контейнере, а php-fpm — в другом и т.д. Может и так, но я делаю так, как мне удобней.
2, 3, 4. Это всё делается через Traefik.
Traefik торчит наружу портами 80, 443
Traefik управляем ssl (автоматически)
nginx-proxy не нужен, потому что всё делает Traefik. Раньше я пользовался nginx-proxy — тоже неплохое решение, но Traefik показался мне удобней.
У всех других контейнеров порты не пробрасываются. Traefik цепляется к ним по докеровской сети.
Как понимаю, речь идет о переходе с Linux Containers на Docker или Podman. По-моему это как раз тот случай, когда лучше изучить, чем не изучать – цинично, но в будущее технологий под эгидой OCI я верю больше :)
никак не могу решиться изучать докер или нет
Докер несомненно самый популярный сейчас движок контейнеризации. Более того, Docker Inc. недавно привлек много мильонов долларов дополнительных инвестиций, так что будьте уверены - все ваши усилия, потраченные на изучение, точно окупятся сторицей.
Статья хорошая для начинающего, я бы добавил сноску про Portainer (docker gui), управлять из гуи проще, визуальное отображение volume и образов приложений, быстрая настройка всех параметров включая авто запуск контейнеров и окружения, а compose вместо возни с файлами превращается в удобный "stacks" где yaml файл можно писать прямо в браузере, как и быстро + удобно настроить переменные окружения.
Если прочитали статью и всё равно ничего не понятно, установите себе виртуалку с Убунту и поднимите там контейнер. Попробуйте всё команды из статьи, очень помогает в понимании работы контейнеров.
PS: не рекомендуется тыкать команды на рабочем сервере в ознакомительных целях😅
Что-то не пойму. А разве управление докер контейнерами при отсутствии рута не решается простым добавлением пользователя в группу docker? Исходя из этого по содержанию статьи разницы между подманом и докером выходит нет.
Несколько различий все же есть:
Запуск контейнеров под пользователями без прав root и управление контейнерами пользователями без прав root – существенно разные вещи
Docker требуется сервис, Podman работает без него (минус единая точка отказа)
Docker использует Container Runtime runc, Podman использует crun
Однако совершенно верно, что с точки зрения рядового пользователя разницы особой нет. Podman изначально разрабатывали так, чтобы внешне он ничем (практически) не отличался
P.S. Я не топлю за Podman, но вижу его применение оправданным в дистрибутивах с сильным влиянием RedHat :)
P.S. Я не топлю за Podman, но вижу его применение оправданным в дистрибутивах с сильным влиянием RedHat :)
Особенно на самых свежих дистрибутивах, где оригинальный докер просто так не поставить. Да и вообще установка оригинального докера может сломать какие-то чисто редхатовские плюшки (например кокпит в последних федорах)
Основы контейнеризации (обзор Docker и Podman)