подумалось такое, возможно противоестественное, а почему бы не использовать докер для "запустить среду, собрать, попробовать", судя по интернетам, такое вполне возможно, хотя как-то кривовато и все же не для этого докер задумывался. Кто-нибуть так его использует?
Здравствуйте, RonWilson, Вы писали:
RW>Привет всем,
RW>подумалось такое, возможно противоестественное, а почему бы не использовать докер для "запустить среду, собрать, попробовать", судя по интернетам, такое вполне возможно, хотя как-то кривовато и все же не для этого докер задумывался. Кто-нибуть так его использует?
Да, у нас так пол компании работает. Есть Докер-контейнер где живет нужная версия GCC и настроены все библиотеки. Контейнер используется как для локальной сборки, так и как часть CI/CD.
Локально остается только запустить контейнер в интерактивном режиме и пробросить в него директорию с исходниками. Очень удобно с точки зрения воспроизводимости ошибок.
Из проблем — посредственная интеграция с CLion, что для ряда сотрудников критична. Те кто в Vim/Emacs или VSCode — всё нормально.
Здравствуйте, Anton Batenev, Вы писали:
RW>> и все же не для этого докер задумывался
AB>Не могу сказать для чего докер задумывался авторами, но его можно использовать только (и только!) для разработки и прогона тестов.
Почему-то его многие пытаются использовать чуть ли не для деплоя продакшен версий
Здравствуйте, RonWilson, Вы писали:
RW> Кто-нибуть так его использует?
Наверное всего так и используют. Плюсы очевидны, у всех фиксированная версия окружения. Это уже потом, кто более продвинулся в своём познании используют контейнеры для деплоя и деливери.
Здравствуйте, RonWilson, Вы писали:
RW>Почему-то его многие пытаются использовать чуть ли не для деплоя продакшен версий
Так и делают, даже на AWS завезли.
Здравствуйте, RonWilson, Вы писали:
RW> Почему-то его многие пытаются использовать чуть ли не для деплоя продакшен версий
Там где хоть чуть-чуть ужесточены требования к ПО (скорость, отказоустойчивость) или есть необходимость в нестандартном окружении (например, спец-требования к сети) использование докера обкладывается кучей костылей и превращается в боль и страдания вплоть до отказа от оного. А вот для тестирования или разработки, где всего этого или нет или по минимуму он как раз очень хорошо заходит.
Почему многие используют в проде я — модно, стильно, молодежно, дешевый MVP из навоза и палок. Сама по себе идея деплоя контейнерами/образами очень даже неплоха, плоха конкретная реализация этой идеи в виде докера.
Здравствуйте, RonWilson, Вы писали:
RW>подумалось такое, возможно противоестественное, а почему бы не использовать докер для "запустить среду, собрать, попробовать", судя по интернетам, такое вполне возможно, хотя как-то кривовато и все же не для этого докер задумывался. Кто-нибуть так его использует?
Я использую, как Dev Environment. Swiss knife, все настроено, скрипты, библиотеки, директории. Сам этот DevEnv крутится прямо в кластере.
Все в восторге, уже 3-я итерация, с каждым новым местом работы. Ушел этот "Setup your environment" день. Как и "Мы обновили продукт ABC, поэтому, каждый, обновите у себя XYZ"
Внутри еще OpenSSH крутится. Пользователи коннектятся по этому внутреннему ssh со своим ssh ключем, так что остается привязка к GitHub/GitLab аккаунту
В последней итерации привязал все к секьюрити:
Kubernetes Service Account -> Hashicorp Kubernetes Auth -> всё остальное через Vault
Все остальное, это AWS IAM, доступ к БД, RabbitMQ. Все по-фен-шую, временное и обновляемое. MFA не нужен. STS credentials и прочие через час теряют актуальность, при этом всегда готовые и актуальные
Люди работают через remote debugging по ssh, у Jetbrains с этим все это хорошо.
Если локально, то эта auth chain сделана через http api сервис, делающий service impersonation. Все credentials обновляются из кластера точно так же, как если бы сервис находился в кластере.
Плюс, девелоперы могут устраивать у себя в этом environment любые ядерные эксперименты. Перезапуск этого env, возвращает все на место, кроме сохраняемых директорий. В нашем случае это "/projects" и "/home". Перманентные добавки вносятся в DevEnv Image и доступны сразу всем
Плюс, перезапуск решает все проблемы с ресурсами, у нас многие забывают остановить свои ресурсоемкие ML расчеты.
Плюс, траффик не ходит от разработчика к облаку. Разработчик может сидеть в интернет кафе, все остальное, тяжелое, крутится прямо в кластере.
---------------------------
Onboarding: разработчик получает VPN и должен сгенерировать ssh ключ
Публичный ключ отдается нам, дальше вся "лапароскопия" по ssh.
Здравствуйте, RonWilson, Вы писали:
RW>Почему-то его многие пытаются использовать чуть ли не для деплоя продакшен версий
Почему нет?
Причем, можно сделать так, что все работает в кластере, изолировано и модульно, при этом не требуется docker опыта ни от разработчика ни допработы для DevOps:
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, RonWilson, Вы писали:
RW>>подумалось такое, возможно противоестественное, а почему бы не использовать докер для "запустить среду, собрать, попробовать", судя по интернетам, такое вполне возможно, хотя как-то кривовато и все же не для этого докер задумывался. Кто-нибуть так его использует?
V_>Я использую, как Dev Environment. Swiss knife, все настроено, скрипты, библиотеки, директории. Сам этот DevEnv крутится прямо в кластере.
Я в этом не особо разбираюсь, а студию так можно развернуть с кучей всякого вроде вспомогательных программ? Вроде где-то читал про идею докера в один докер — один сервис или это ерунда всё?
V_>>Я использую, как Dev Environment. Swiss knife, все настроено, скрипты, библиотеки, директории. Сам этот DevEnv крутится прямо в кластере.
RW>Я в этом не особо разбираюсь, а студию так можно развернуть с кучей всякого вроде вспомогательных программ? Вроде где-то читал про идею докера в один докер — один сервис или это ерунда всё?
Это для CLI только, GUI не будет.
GUI-full, удаленно, через ssh
Один сервис — (PID-0) процесс, да, это правильный подход для самих runtime компонентов. Так что lifetime этого компонента дается на откуп оркестратору (Куберенетес или похожее). Сами приложения в PROD/UAT/QA/Dev как раз и есть эти приложение/контейнер, абсолютно идентичные между envs. Сами контейнеры легковесные, тот же Alpine а то и distroless/scratch. Врутри только сам foreground pid 0 процесс безо всяких supervisord/s6-overlay и прочего
В случае же Dev Environment это не типовое, но прекрасно работающее решение
Здравствуйте, Anton Batenev, Вы писали:
AB>Почему многие используют в проде я — модно, стильно, молодежно, дешевый MVP из навоза и палок. Сама по себе идея деплоя контейнерами/образами очень даже неплоха, плоха конкретная реализация этой идеи в виде докера.
Похоже, у вас там не очень разбираются в вопросе, раз само слово Docker на слуху с характерной для дилетантов ненавистью
Люди используют контейнеры. Приложение -> контейнеризация -> оркестратор контейнеров. Сам докер уже и завершится ни сегодня, так завтра.
Зачем деплой вручную реализовывать? Есть же TektonCD, например, весьма container-native с неограниченной (любой docker open container image), в отличие от все-в-одном монстров.
Здравствуйте, Anton Batenev, Вы писали:
RW>> Почему-то его многие пытаются использовать чуть ли не для деплоя продакшен версий AB>Там где хоть чуть-чуть ужесточены требования к ПО (скорость, отказоустойчивость) или есть необходимость в нестандартном окружении (например, спец-требования к сети) использование докера обкладывается кучей костылей и превращается в боль и страдания вплоть до отказа от оного.
У нас под Docker'ом работает DPDK, без всяких проблем. Чем конкретно Docker мешает скорости и отказоустойчивости?
Да, те кто делают отказоустойчивость без кластерного failover'а — сейчас занимаются чем-то не тем.
