Контакты

Достижения

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

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

Все теги (42)

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

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

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

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

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

    3. ansible, gitlab-ci

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

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

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

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

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

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

    gecube
    @gecube
    системный администратор, программист... все дела..
    Смотрите сами - перевешивают ли выгоды от работы с этой компанией, чем трудоустройство в другую компанию по ТК. Действительно, Вы теряете в больничных, теряете в правах - в случае косяка, работодатель может отобрать всю Вашу собственность. Пенсии скорее всего проблемой не будут, т.к. ИП платит взносы в пенсионный фонд. Дополнительно работодатель может разорвать контракт с Вами в любой момент. Ну, и выходных у Вас не будет - т.к. в договоре с ИП должен быть указать конкретный объем работ и конкретный срок, чтобы это не выглядело как попытка ухода от налогов работодателем (а штрафы там будь здоров и есть разъяснения судов и налоговой инспекции по этому поводу).
    Ещё Вы ничего не приобретаете. Условно - налоги платите Вы сами, никто не будет платить ипшнику на 40% больше, чем штатному работнику - это оптимизация выгодна только лишь работодателя, а не сотруднику.
    Плюс, если компания иностранная, может быть очень неприятно попасть на валютный контроль и не получить свои честно заработанные деньги от слова "никогда".
    Ответ написан