Желательно, чтобы в Helm была специальная кнопка «Сделай мне хорошо уже наконец!» — и оно сразу становилось бы хорошо. Kubernetes позволяет это делать.
…
Казалось бы, естественно Helm позволяет это делать. Потому что иначе, в чем вообще был смысл создавать Helm?
Но оказывается, нет!
[Картинка со схемой]
Автоматизация окружения отсутствует.
Вот бы тут подробнее… «Kubernetes позволяет это делать.» — это в смысле «вот API, с помощью которого можно сделать хорошо»?
Я порвал листки с расчетами, встал и тихонько двинулся в свою каюту с таким чувством, будто совершил преступление. К нам залетел гость из космоса, такой визит случается — как знать? — раз в миллионы, нет — в сотни миллионов лет. И вот — из-за свинки, Ле Манса, его железной рухляди, пьяного метиса, инженера с его шурином и моих упущений — он прошёл у нас сквозь пальцы, чтобы растаять, как призрак, в бесконечном пространстве.
Пожалуй журналистам стоит проштудировать «Основы космической навигации и космодромии» Краффта перед публикацией шокирующих новостей...
Мобильная версия nix.ru ;] Чтобы переключиться в списке товаров на десктопную версию, нужно нажать на ссылку в футере. Но как только докрутил до него, то подгружается новая страница товаров и… всё заново.
Было взято готовое приложение и была задача собрать его в образ.
Обычно если брать что-то готовое на java, то будет maven или gradle, если php, то скорее всего composer, а в мире js нет какого-то лидера среди утилит сборки (это только наполовину субъективное мнение, а наполовину — статистика по заказчикам). Так что думаю полезнее будет описать отдельной статьёй сборку другого приложения с применением yarn.
The exact hardware specs of the Compo Machine are not yet known but will be something like the following
CPU: Core i7
RAM: 16GB RAM
Graphics: NVIDIA Titan Black w/ 6GB RAM
OS: Win8.1 64bit with then latest DirectX and stable NVidia drivers.
checkinstall обёртка над make, которая, в свою очередь, использует installwatch — отслеживатель работы с файлами для любого процесса. Теоретически можно установить Chefdk / Ansible и потом по логу удалить всё ненужное. Но даже если эта схема заработает, то: 1) installwacth нужно каким-то образом добавить в систему и потом его удалить. 2) время сборки будет потрачено на установку/удаление того, что можно скачаться один раз (ansible+python). 3) чтобы не раздувать образ, нужно удалять/устанавливать на каждой стадии — ещё больше времени израсходуется впустую. 4) Установить и удалить ansible+python можно и без слежки за файлами, а, например, через apt-get, но два предыдущих пункта делают это совершенно бесполезным.
Цель описанных контейнеров — не собирать инструменты, которые можно собрать один раз, оформить в виде docker-образа и потом просто скачать.
Да уж, вопрос объёмный. Много интересного можно найти вот здесь: https://github.com/veggiemonk/awesome-docker. К этому можно добавить CI: собирать и выкатывать можно используя возможности Travis, shippable, gitlab, упомянутый jenkins и т.д.
После релиза 0.27 узнали в группе pro_ansible про ansible container —
этот проект больше всего похож на dapp. Тут и сборка, и выкат в Kubernetes, и даже монтируемый образ с python и ansible, как наш образ dappdeps/ansible (у нас правда один образ работает со всеми дистрибутивами). Пока смотрим, что можно бы у них почерпнуть и чем посодействовать.
Кэш отличается: у нас кэш можно привязать к изменениям в git, а в ansible-container можно привязать к ansible ролям.
Попробую разъяснить сразу два момента. Упрощённо dapp работает таким образом, что сборка разделена на 4 стадии. Каждая стадия это образ (с тэгом), который можно запушить в registry. Таким образом, для одной сборки в registry попадёт несколько тэгов. По мере разработки появляется дерево образов, когда сборка, например, новой ветки основана на стадии предыдёщей сборки — это и есть кэширование.
Проблем с очисткой как таковой в целом нет — dapp умеет смотреть что есть в registry и давать команды на удаление. Это скорее неудобство, что gitlab при запуске задачи ci не даёт токен с правами на удаление образов в Registry, хотя пользователь такие права имеет и приходится создавать токен отдельно — такая же ситуация будет с любым registry.
Про kubelet очень просто — он чистит локальный registry от тэгов, которых нет в ресурсах. И, если собирать dapp-ом на том же docker-е, то возникает ситуация, что dapp собрал стадию, а kubelet её тут же удалил.
По поводу использования helm всё зависит как Вы организуете CI/CD для выкатки чартов, но тут так-же всё можно сделать достаточно красиво.
Критичная фича — ожидание выката helm релиза. dapp следит за этим, а Clusters надо пробовать. Это всё конечно «исторически сложилось» — выкат через helm был реализован в dapp, ещё когда много клиентов были на 9-ой версии gitlab, где интеграции с k8s не было.
По поводу установки GitLab в k8s — быстрее поставить в minikube
Тут полностью согласен, установка в куб больших приложений очень проста. Цель статьи показать как у нас в большинстве проектов настроен CI и получить стенд для экспериментов с gitlab + k8s.
dapp умеет работать с remote docker, есть успешные попытки запускать сборку в pod-е с docker-dind и dapp. Но основное препятствие использовать gitlab в кубе для сборки — как быть с монтированием. Т.е. вариант с двумя ВМ заведомо рабочий для всех вариантов сборки. А вариант с gitlab в кубе это более сложная конструкция, которая тянет на отдельную статью.
Кэширование есть и в docker-е, но в Dappfile можно определить зависимость пересборки от изменений в определённых файлах — такого нет в gitlab. И ещё проблема — чистка ненужных образов, gitlab тут не сильно помогает, даже немного вредит, не давая прав через CI_JOB_TOKEN.
С выкатом через интеграцию с kubernetes не сталкивался вплотную, но из документации складывается впечатление, что это некий свой выкат через использование API или kubectl. Второй вариант — Clusters использует helm, но ещё не совсем готов. Если clusters в Gitlab CE будет уметь ожидать успешности выката (запуск helm это выдача задания в tiller и выход), то будем брать на вооружение.
GitLab НЕ в Kubernetes
Некоторым заказчикам мы ставим gitlab в Kubernetes, эту тему можно даже в отдельную статью превратить. А для демонстрационного стенда проще настроить две ВМ — gitlab в vagrant-е + minikube. Есть особенность, что если собирать образы тем же docker, который установлен в minikube, то kubelet будет уничтожать образы стадий по мере сборки. Поэтому для сборки нужен свой отдельный docker, настройка получается сложнее. Опять же можно использовать ВМ по отдельности, например, запустить только gitlab, чтобы отладить пайплайн.
Вот бы тут подробнее… «Kubernetes позволяет это делать.» — это в смысле «вот API, с помощью которого можно сделать хорошо»?
Помню, что Colorer очень крутой и точно поддерживал regexp-ы, вполне возможно, что re из статьи даже править не придётся ;)
Можно делать настройки для языков. https://code.visualstudio.com/docs/getstarted/settings#_language-specific-editor-settings
Не в курсе внутренней кухни, но если плагин rainbowcsv добавляет язык csv, то будет примерно такая настройка:
Пожалуй журналистам стоит проштудировать «Основы космической навигации и космодромии» Краффта перед публикацией шокирующих новостей...
Мобильная версия nix.ru ;] Чтобы переключиться в списке товаров на десктопную версию, нужно нажать на ссылку в футере. Но как только докрутил до него, то подгружается новая страница товаров и… всё заново.
А ведь когда-то так и было: драйвера от сидирома в интернете, драйвера от модема на диске.
Оказывается пропала одна строчка, из-за этого скрипт для phantomjs не хотел останавливаться.
https://github.com/flant/grafana-statusmap/pull/15
Можно обновиться из мастера. Когда будет версия 0.0.2 в репозитории Grafana, знает только daniellee, PRы там по месяцу могут висеть :(
Действительно, с плагином ошибка 500, а без него всё ок. Завёл issue: https://github.com/flant/grafana-statusmap/issues/10
@и ошибки это из php, там правда смысл несколько иной: http://php.net/manual/ru/language.operators.errorcontrol.phpРазбор не читай — сразу отвечай.
Было взято готовое приложение и была задача собрать его в образ.
Обычно если брать что-то готовое на java, то будет maven или gradle, если php, то скорее всего composer, а в мире js нет какого-то лидера среди утилит сборки (это только наполовину субъективное мнение, а наполовину — статистика по заказчикам). Так что думаю полезнее будет описать отдельной статьёй сборку другого приложения с применением yarn.
https://2015.revision-party.net/compos/pc
checkinstallобёртка над make, которая, в свою очередь, используетinstallwatch— отслеживатель работы с файлами для любого процесса. Теоретически можно установить Chefdk / Ansible и потом по логу удалить всё ненужное. Но даже если эта схема заработает, то: 1) installwacth нужно каким-то образом добавить в систему и потом его удалить. 2) время сборки будет потрачено на установку/удаление того, что можно скачаться один раз (ansible+python). 3) чтобы не раздувать образ, нужно удалять/устанавливать на каждой стадии — ещё больше времени израсходуется впустую. 4) Установить и удалить ansible+python можно и без слежки за файлами, а, например, через apt-get, но два предыдущих пункта делают это совершенно бесполезным.Цель описанных контейнеров — не собирать инструменты, которые можно собрать один раз, оформить в виде docker-образа и потом просто скачать.
Как оказалось, этот подход похож на то, что делают в Ansible Container http://docs.ansible.com/ansible-container/conductor.html
Да уж, вопрос объёмный. Много интересного можно найти вот здесь: https://github.com/veggiemonk/awesome-docker. К этому можно добавить CI: собирать и выкатывать можно используя возможности Travis, shippable, gitlab, упомянутый jenkins и т.д.
До перехода на ansible мы знали про rocker — это довольно известная утилита, но в этом году у проекта какой-то кризис (https://github.com/grammarly/rocker/issues/199)
После релиза 0.27 узнали в группе pro_ansible про ansible container —
этот проект больше всего похож на dapp. Тут и сборка, и выкат в Kubernetes, и даже монтируемый образ с python и ansible, как наш образ dappdeps/ansible (у нас правда один образ работает со всеми дистрибутивами). Пока смотрим, что можно бы у них почерпнуть и чем посодействовать.
Кэш отличается: у нас кэш можно привязать к изменениям в git, а в ansible-container можно привязать к ansible ролям.
.
Попробую разъяснить сразу два момента. Упрощённо dapp работает таким образом, что сборка разделена на 4 стадии. Каждая стадия это образ (с тэгом), который можно запушить в registry. Таким образом, для одной сборки в registry попадёт несколько тэгов. По мере разработки появляется дерево образов, когда сборка, например, новой ветки основана на стадии предыдёщей сборки — это и есть кэширование.
Проблем с очисткой как таковой в целом нет — dapp умеет смотреть что есть в registry и давать команды на удаление. Это скорее неудобство, что gitlab при запуске задачи ci не даёт токен с правами на удаление образов в Registry, хотя пользователь такие права имеет и приходится создавать токен отдельно — такая же ситуация будет с любым registry.
Про kubelet очень просто — он чистит локальный registry от тэгов, которых нет в ресурсах. И, если собирать dapp-ом на том же docker-е, то возникает ситуация, что dapp собрал стадию, а kubelet её тут же удалил.
Критичная фича — ожидание выката helm релиза. dapp следит за этим, а Clusters надо пробовать. Это всё конечно «исторически сложилось» — выкат через helm был реализован в dapp, ещё когда много клиентов были на 9-ой версии gitlab, где интеграции с k8s не было.
Тут полностью согласен, установка в куб больших приложений очень проста. Цель статьи показать как у нас в большинстве проектов настроен CI и получить стенд для экспериментов с gitlab + k8s.
dapp умеет работать с remote docker, есть успешные попытки запускать сборку в pod-е с docker-dind и dapp. Но основное препятствие использовать gitlab в кубе для сборки — как быть с монтированием. Т.е. вариант с двумя ВМ заведомо рабочий для всех вариантов сборки. А вариант с gitlab в кубе это более сложная конструкция, которая тянет на отдельную статью.
Кэширование есть и в docker-е, но в Dappfile можно определить зависимость пересборки от изменений в определённых файлах — такого нет в gitlab. И ещё проблема — чистка ненужных образов, gitlab тут не сильно помогает, даже немного вредит, не давая прав через CI_JOB_TOKEN.
С выкатом через интеграцию с kubernetes не сталкивался вплотную, но из документации складывается впечатление, что это некий свой выкат через использование API или kubectl. Второй вариант — Clusters использует helm, но ещё не совсем готов. Если clusters в Gitlab CE будет уметь ожидать успешности выката (запуск helm это выдача задания в tiller и выход), то будем брать на вооружение.
Некоторым заказчикам мы ставим gitlab в Kubernetes, эту тему можно даже в отдельную статью превратить. А для демонстрационного стенда проще настроить две ВМ — gitlab в vagrant-е + minikube. Есть особенность, что если собирать образы тем же docker, который установлен в minikube, то kubelet будет уничтожать образы стадий по мере сборки. Поэтому для сборки нужен свой отдельный docker, настройка получается сложнее. Опять же можно использовать ВМ по отдельности, например, запустить только gitlab, чтобы отладить пайплайн.
Это «Несбыточный свой путь (ария Милиневского)» из техно-оперы В.Аргонова «2032. Легенда о несбывшемся грядущем» http://argonov.ru/2032.html