Pull to refresh

Comments 13

Покопался немного на праздниках, докладываю как работает «web terminal» и «auto deployment». И то и другое — интерфейсы к Kubernetes. У вас где-то есть настроенный Kubernetes (например, готовый от Google Cloud или настроенный на AWS). Вы в настройках проекта выбираете «интегрировать с Kubernetes», вбиваете параметры доступа. После чего у волшебной палочки появляются два новых режима:

  1. «Audo Deployment» — это всего лишь wizard, который генерирует правильный CI конфигурационный файл для деплоя в Kubernetes. Правильный еще и в том плане, что проставляет нужные теги для работы web terminal.
  2. «Web Terminal»: если для проекта настроена интеграция с Kubernetes, то по клику на «web terminal» Gitlab попробует сделать SSH-из-браузера (как у Amazon Lightsail) на нужный Docker контейнер, куда приложение было раскатано. Чтобы магия работало, для контейнера должен быть проставлен правильный тег. Как раз его и проставляет скрипт деплоя, сгенерированный в шаге №1.


  3. Подводя итоги: работает только на Kubernetes, скрипт деплоя нужно писать самому, чтобы работал web terminal скрипт должен правильно все протегировать. Есть визард. Environment'ы сами по себе ничего не делают, просто связки имя-url, которые в интерфейсе обрастают кучей кнопочек вида «деплоить сюда», «web terminal сюда», «зайти на url» и так далее.

    Поправьте меня, пожалуйста, если я что неправильно выкопал. Ну и, традиционно, с наступившим!

Спасибо, отличное дополнение!


Auto Deployment прошел всего одну итерацию разработки и там пока что только для Kubernetes/OpenShift есть шаблон, но в будущем должны появиться и другие. Предполагаю, что и терминал должен заработать с любым хостом, куда у GitLab есть доступ (а он и так есть, если настроен деплой).


скрипт деплоя нужно писать самому

К моменту настройки деплоя через GitLab CI хоть какой-то скрипт деплоя уже наверняка есть (bash/ansible/etc.). Нужно только дать GitLab права на его запуск (credentials в секретные переменные положить). Или вы имели в виду что-то иное?

К моменту настройки деплоя через GitLab CI хоть какой-то скрипт деплоя уже наверняка есть (bash/ansible/etc.). Нужно только дать GitLab права на его запуск (credentials в секретные переменные положить). Или вы имели в виду что-то иное?


Из анонсов и документации можно сделать неправильный вывод, что «auto deploy» — это какая-то магия, которой указываешь пальцем на голую машину с SSH, и оно волшебным образом туда что-то «деплоит», а потом еще и ssh-из-веба. На практике деплой как писался ручками, так и пишется, «auto deploy» предлагает простенький скелет, чтобы развернуть такое же простенькое веб приложение в kubernetes контейнер.

Обратите внимание на ретроспективное когнитивное искажение, после прочтения комментариев вы обнаруживаете, что всегда об этом знали ^_^
Насчёт какого-то скрипта далеко не факт. Деплоишь ручками, читаешь про чудеса CI/CD, решаешь попробовать что-то популярное и понимаешь что нужно кучу вещей писать руками, что и останавливалось от разработки баш-скриптов.

Кстати, говоря о теге для контейнера вы вот этот блок имеете в виду?


  environment:
    name: review/$CI_BUILD_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.$KUBE_DOMAIN
    on_stop: stop_review
https://docs.gitlab.com/ce/project_services/kubernetes.html

Я нежно люблю и активно исползьую gitlab и этот релиз мне нравится, однако приоритеты разработчиков иногда вводят в ступор. В 8.14 поломали совместимость со всеми текущими версиями git (точнее это git поломал, но результат от этого не меняется) и месяц было невозможно никому пушить в protected branch. Починка там была почти тривиальная, но по непостижимым для меня причинам она ждала 8.15, хотя просто просилась и кричала войти в скорейший, минорный релиз 8.14.х

То, что авторы прокручивают новые свистелки — это конечнно хорошо, но то, что они стремительно теряют интерес к старым — это грустно. Месяца три как ждем элементарной починки для registry чтоб с ним наконец можно было работать, но нет — новые странные штуки появляются, а допилить то, что было выпущено несколько месяцев назад — никак.

А этот баг с registry уже отмечен в трекере? Если да, дайте ссылку, чтобы хабровчане пришли и наплюсовали его, авось совместными усилиями повысим приоритет.

Да-да, элементарно библиотеки обновить не могут, уж 2 месяца issue24039 висит и даже в бэклог не попало.
Вот чего _сильно_ не хватает в gitlab- это возможность писать группу комментириев (как в gerrit).
1. Это полезно, когда читая 10й файл мерж-реквеста понимаешь, что комментарий к первому файлу лучше переписать (или вообще удалить).
2. Когда есть 10 комментариев, то логично получить одно письмо, а не 10 (а то у тимлидов столько сыпется всего, что не поймёшь).

Ещё бы custom permissions допили, было чудный подарок в Новый Год.


Спасибо за перевод.

Как следствие, в данном релизе содержится множество изменений, делающих работу с GitLab еще более приятной.

Ну спасибо.
image

Sign up to leave a comment.