Контакты

Достижения

Все достижения (3)

Наибольший вклад в теги

Все теги (42)

Лучшие ответы пользователя

Все ответы (67)
  • Как правильно организовать разработку с использованием docker?

    gecube
    @gecube
    системный администратор, программист... все дела..
    Черновой ответ, потому что у всех детали могут отличаться - делайте как Вам удобнее.

    1. Есть принципиально два подхода. Первый - один репозиторий - один артефакт. Он достаточно удобен, т.к. позволяет раздавать доступы на репозитории разным командам, если они пилят разные модули. Так же это в рамках гита позволяет удобно реализовать разные релизные циклы для разных модулей. С другой стороны - сразу получаете проблему интеграции всех этих репозиториев в единую систему. Обычно решается каким-то мета-репозиторием, который знает как собрать проект из кусочков. Или инклюдит все остальные репозитории как субмодули. Еще если маленьких репозиториев очень много и нужно вносить параллельные изменения в несколько сразу - это очень неудобно для разработчиков. Вторая крайность - это монорепозиторий. Когда ВЕСЬ проект состоит из одного репозитория. Это очень удобно в ситуации, когда у Вас только ОДНА, крайняя версия продукта. Т.к. всегда все собирается из одного коммита и либо все сразу срастается и есть гарантии совместимости всех модулей, либо надо исправлять код ) При этом зачастую приходится очень четко продумывать структуру проекта (например, раскладывать каждый отдельный модуль в отдельный каталог), теряете возможность работы с внешними подрядчиками (придется им заводить отдельные репки + настраивать синхронизацию), делать всякие обертки, чтобы не собирать весь проект, а только изменившиеся части, т.к. сборка всего может быть очень долгой. Но, да, этот подход тоже имеет право на жизнь. Тем более пока не попробуете сами - точно не сможете понять, что лучше
    docker-compose - это хорошо для разработки и моделирования кучки сервисов. Для продакшена не очень хорошо.

    2. Идеально - один контейнер - один сервис. Но для целей разработки можно использовать контейнеры как средство доставки чего бы то ни было и там рождаются кадавры с несколькими сервисами в одном контейнере. Но для продакшена это не очень.

    3. ansible, gitlab-ci

    4. все имеет значение. Зависит от ваших возможностей и задач. Точно стоит избегать всяких OpenVZ, лучше всего деплоится на настоящие виртуальные машины. Как правило они на KVM технологии. По операционной системе - лучше брать то, с чем умеете работать, либо можете привлечь специалистов. Т.е. популярные варианты - centos, ubuntu, debian. Все остальное можно рассмотреть только в случае каких-либо _особых_ требований. Например, очень крутая штука CoreOS, если запускать ТОЛЬКО лишь контейнеры - ничего лишнего, атомарные обновления, но хорошо это работать будет только на виртуалках, а если надо запускаться на железном сервере ? То тут уже нюансы

    5. никак. Она с докерами никак не дружит.

    6. Думать. Проектировать. Очень важно понимать как будет запускаться приложение, сколько будет реплик, как они будут взаимодействовать, делить общие ресурсы (файлы, записи в БД, очереди и пр). Касательно файлов - для докер-контейнеров - чтобы обеспечить их сохранность, все нужное нужно писать либо в bind mount, либо в volume - тогда данные не пропадут при удалении контейнера.

    > Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так?

    Совсем высокоуровнего - да, так.
    Ответ написан
    4 комментария
  • Нормальная ли конфигурация пк?

    gecube
    @gecube
    системный администратор, программист... все дела..
    Ответить на вопрос можно только зная финансовые возможности и зная какие задачи будут выполняться на ПК
    В целом - выглядит относительно сбалансированно. Единственное, что ssd на 120ГиБ - это катастрофически мало. Рекомендую рассматривать модели объемом 256ГиБ - 512ГиБ. Тогда не будете испытывать болей навроде "винда накачала апдейтов - место закончилось"
    Ответ написан
    1 комментарий
  • Что за ошибка докера?

    gecube
    @gecube
    системный администратор, программист... все дела..
    ну, все написано - когда монтируете, то можете только файл на файл или каталог на каталог монтировать. Иногда бывает, что если в volume слева указан файл, который на хосте не существует, то докер сходит с ума. И создает вместо него каталог с правами root:root.
    Какое может быть решение? Для начала прекратить пользоваться упрощенным синтаксисом -v в docker run или volumes в docker-compose, а использовать расширенный синтаксис mount (который с --mount). Тогда, если на хосте нет нужного файла, то докер контейнер ТУПО не стартанет и будет внятное сообщение об ошибке вроде:

    docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /home/local/georg.gaal/formulas.
    See 'docker run --help'.


    При этом Вы еще бонусом и получаете то, что докер не будет пытаться изменить права на каталог. А создаваемые внутри файлы будут с теми правами, которые установлены внутри контейнера - сплошная лепота. Минус в том, что все необходимые каталоги и файлы для запуска контейнера надо создавать заранее. Т.е. уже коллегам надо отдавать докер-компоуз файл плюс bash-скрипт
    Ответ написан
    2 комментария
  • Keepalived. VRRP. Будет ли работать Keepalived, если 2 сервера в разных ЦОД?

    gecube
    @gecube
    системный администратор, программист... все дела..
    Нет, keepalived не будет работать в разных ЦОД. Но есть исключение - если сделаете L2VPN или типа того.

    Рассмотрите более продвинутые варианты обеспечения отказоустойчивости (вроде BGP анонсов, либо закройтесь внешним прокси вроде Qrator/cloudflare). И ОБЯЗАТЕЛЬНО ПРОКОНСУЛЬТИРУЙТЕСЬ с сотрудниками ЦОД - они наверняка хорошо знают свою инфраструктуру и могут предложить варианты (например, плавающий между ЦОДами IP адрес, если ЦОДы принадлежат одному владельцу)
    Ответ написан
  • Как правильно работать с пользователями в Docker-контейнерах?

    gecube
    @gecube
    системный администратор, программист... все дела..
    > Как работает параметр user при запуске докер-контейнеров и, самое главное - как обрабатывать его при написании своих Dockerfile'ов?

    никак. Параметр user это костыль, который позволяет софт запускать не от root'ового пользователя. Объяснять почему запускать в докере под пользователем 0 (root) что-либо - долго, но если кратко, то это очень плохо и не секурно. Соответственно, правильный путь Вы уже поняли:

    1. определять entrypoint контейнера как свой самописанный docker-entrypoint.sh скрипт
    2. в docker run оставить возможность передать ключ (точнее - переменную среды) USER
    3. в docker-entrypoint.sh его (ее, переменную среды) подхватывать и изменять через chmod/chown нужные файлы в bind-mount (каталогах, доступных и в контейнере, и на хосте) и через утилиту gosu переключаться в нужного пользователя
    4. и только как завершающий этап - запускать свой сервис в докере


    Что еще добавить. Все эти проблемы с chown/chmod возникают только если необходимо перегонять файлы между контейнером и хостом. Если этой задачи не стоит, то и все приседания и не нужны. А если все-таки нужно, то есть еще два способа это сделать без колдования с правами:
    • команда docker cp
    • использование pipe: docker exec container_name cat MY_FILE > path_on_host или аналогично
    Ответ написан
    4 комментария