Comments 22
Эм, я правильно понимаю, что отключены чуть ли не все средства безопасности SSH?
Ещё я не понял, зачем применяются одновременно SSH_PRIVATE_KEY и USER_PASS
Ещё я не понял, зачем применяются одновременно SSH_PRIVATE_KEY и USER_PASS
По первому вопросу, если честно не отвечу, поскольку не знаю, какие есть и как их включить, если подскажете, то я попробую решить этот вопрос и обновить статью.
По второму вопросу. Там смотрите есть два сервера — первый это тот который находится в Gitlab и SSH_PRIVATE_KEY — это его ключ, он нужен чтобы мы могли проводить над ним разные манипуляции (создавать папки, клонировать репозиторий и т.п.). И второй — это пароль от сервера куда мы деплоим.
По второму вопросу. Там смотрите есть два сервера — первый это тот который находится в Gitlab и SSH_PRIVATE_KEY — это его ключ, он нужен чтобы мы могли проводить над ним разные манипуляции (создавать папки, клонировать репозиторий и т.п.). И второй — это пароль от сервера куда мы деплоим.
какие есть и как их включить
stricthostkeychecking=no это явное отключение, например
разные манипуляции (создавать папки, клонировать репозиторий и т.п.)
А разве гитлаб не клонирует репозиторий для CI самостоятельно? Когда я гонял тесты на GitLab CI, я обходился без этого
пароль от сервера куда мы деплоим
А вот тут как раз и нужно использовать ключи, а не пароль. И вообще пароли в SSH в идеале никогда не нужно использовать
А разве гитлаб не клонирует репозиторий для CI самостоятельно? Когда я гонял тесты на GitLab CI, я обходился без этого
У меня так не получилось, если честно( Если запускать билд и тесты, то да, без этого можно обойтись, но если нужно деплоить, то я не знаю как без этого и нигде не написано, можно ли обойтись без этого.
stricthostkeychecking=no это явное отключение, например
К сожалению с включением не работает, собирал это место скрипта из разрозненных ответов, подобно вот этому: stackoverflow.com/a/47536235/10239772
А также из ответа мне в toster от одного из товарищей toster.ru/q/555101
Вопрос, а чем опасно отключение этой настройки в данном случае? Почему ключи SSH безопаснее паролей?
подобно вот этому
Ну по этой ссылке делается git push с тегом, там все эти манипуляции действительно необходимы
К сожалению с включением не работает
Потому что, наверно, ssh ругался, что он не знает публичного ключа гитбала, а вы вместо добавления ключа в доверенные просто отключили проверку ключей и открыли дорогу MITM-атакам :) (хотя, конечно, в инфрастуктуре гитлаба MITM-атака, наверно, очень маловероятна, но всё равно подобные отключения мне как-то не очень нравятся)
Почему ключи SSH безопаснее паролей?
Я не знаю всех тонкостей аутентификации SSH, и на этот вопрос какие-нибудь спецы могут ответить лучше чем я (если они тут есть)
а можете мне скинуть пример gitlab-ci.yml файла для прогонки тестов на Go? Где не видел, везде делали go get проекта, а не пользовались уже тем, что CI склонировал
Я go не юзаю, я питонист. Но у меня такое прекрасно работало, и я не думаю, что в go (и в любом другом языке) это должно как-то принципиально отличаться
В этом моём gitlab-ci.yml pip install -e . — установка проекта из текущего каталога, где текущим каталогом является как раз склонированный репозиторий
(правда, стоит заметить, что у меня был свой локалхостовый гитлаб, может его CI чем-то отличается от обычного гитлаба, не знаю)
В последнее время только у меня проблемы с CI/CD GitLab? постоянно ошибка:
ERROR: Job failed (system failure): error during connect: Get https://***.**.**.**:2372/v1.18/containers/******/json: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "root") (executor_docker.go:965:2s)
Стоп стоп стоп
Создание приватного ключа на сервере, кто же так делает?
Cуть CI/CD для абстрактного проекта такова:
1. вы пушите код в репозиторий
2. сервер сборок (CI-сервер) (либо по триггеру от шага 1, либо проверяет сам наличие изменений и если они есть) клонирует репозиторий (точнее даёт команду нужному «агенту сборки» ) и запускает некие этапы сборки (обычно это `build — test — deploy`), которые указаные в конфигурации
3. на этапах могут появляться
Касательно, GitLab:
1. Конфигурация сборки — это .gitlab-ci.yml файл. Он ОБЫЧНО должен быть в репозитории того приложения, которое деплоится, т.к. только он может быть нестандартным. В общем, каждый репозиторий сам должен «знать» как себя деплоить.
2. При запуске pipeline-а проект (если брать настройки по умолчанию: см. Git strategy) КЛОНИРУЕТСЯ на runner-е. Runner — это «агент сборки», на котором, собственно и происходит этап (выбирается из списка доступных по tag-у). Так что ваши действия по клонированию репозитория в
3. ставить приложение, залезая на сервер, добавляя там файлик сервиса и копируюя в каталоги свои файлы — это кустарщина. Если хотите «по-взрослому», то на этапе build у вас после компиляции Go-бинарника, должен собраться RPM-пакет, который устанавливается уже на любой сервер (а не только на тот, который вы предварительно залезете и ручками его настроите). Этот RPM и будет содержать все необходимые файлы (включая файл ServiceName.service и все другие). Кроме того, деплой приложения (если на другой сервер) сведётся к
4. На каком runner-е у вас запускается pipeline? не на том же VDS-е случаем? тогда свистопляски с SSH — не нужны.
5. Преимущество SSH-ключей перед паролями в том, что это: безопасно (гуглите «асимметричное шифрование»), и легко автоматизируется, т.к. не требует `sshpass`, а уже «встроено» в ssh: ssh -i /another/private.key
6. к слову у GitLab-а есть deploy keys, так что не надо раскрывать генерировать новые ключи или раскрывать свой пароль для доступа к репозиторию
7. пока писал, увидел, что сборка происходит в docker-контейнере (из-за чего и клонируется в него репозиторий?), тогда подключите volumes и всё написаноне мной выше — остаётся в силе )))))
З.Ы. Know your tools…
1. вы пушите код в репозиторий
2. сервер сборок (CI-сервер) (либо по триггеру от шага 1, либо проверяет сам наличие изменений и если они есть) клонирует репозиторий (точнее даёт команду нужному «агенту сборки» ) и запускает некие этапы сборки (обычно это `build — test — deploy`), которые указаные в конфигурации
3. на этапах могут появляться
артефакты сборки, которые могут быть доступны в веб-интерфейсе и передаются между этапами (например, после build появляется некий (раз у вас CentOS) RPM-пакет, который на этапе deploy, устанавливается на целевые системы.Касательно, GitLab:
1. Конфигурация сборки — это .gitlab-ci.yml файл. Он ОБЫЧНО должен быть в репозитории того приложения, которое деплоится, т.к. только он может быть нестандартным. В общем, каждый репозиторий сам должен «знать» как себя деплоить.
2. При запуске pipeline-а проект (если брать настройки по умолчанию: см. Git strategy) КЛОНИРУЕТСЯ на runner-е. Runner — это «агент сборки», на котором, собственно и происходит этап (выбирается из списка доступных по tag-у). Так что ваши действия по клонированию репозитория в
before_script — лишние, если этот .gitlab-ci.yml лежит в том же репозитории, что и проект. GiLab Runner сам всё делает.3. ставить приложение, залезая на сервер, добавляя там файлик сервиса и копируюя в каталоги свои файлы — это кустарщина. Если хотите «по-взрослому», то на этапе build у вас после компиляции Go-бинарника, должен собраться RPM-пакет, который устанавливается уже на любой сервер (а не только на тот, который вы предварительно залезете и ручками его настроите). Этот RPM и будет содержать все необходимые файлы (включая файл ServiceName.service и все другие). Кроме того, деплой приложения (если на другой сервер) сведётся к
rsync/scp app.rpm <remote-server>:/tmp && ssh <remote-server> yum/dnf install /tmp/app.rpm. такой же простой будет откат, если вдруг новая версия сервиса оказалась непригодной.4. На каком runner-е у вас запускается pipeline? не на том же VDS-е случаем? тогда свистопляски с SSH — не нужны.
5. Преимущество SSH-ключей перед паролями в том, что это: безопасно (гуглите «асимметричное шифрование»), и легко автоматизируется, т.к. не требует `sshpass`, а уже «встроено» в ssh: ssh -i /another/private.key
6. к слову у GitLab-а есть deploy keys, так что не надо раскрывать генерировать новые ключи или раскрывать свой пароль для доступа к репозиторию
7. пока писал, увидел, что сборка происходит в docker-контейнере (из-за чего и клонируется в него репозиторий?), тогда подключите volumes и всё написаноне мной выше — остаётся в силе )))))
З.Ы. Know your tools…
1) посоветовал бы использовать dep или vgo для того чтобы управлять зависимостями. Если уж все таки через go get, то go get -d ./… сразу все выкачает и не надо будет тянуть каждый пакет отдельно
2) внутри раннера уже доступно содержимое репозитория, только артефакты (производные сборки полученные уже внутри стейджа) нужно копировать между стейджами
3) Ключ безопаснее пароля хотя бы тем, что состоит из двух частей и потеряв половину ключа (открытый ключ) злоумышленник сможет только шифровать сообщения, но не расшифровывать. Ключ нужно сгенерировать один раз на сервере и в CI передавать только публичный ключ, а приватный должен храниться на сервере.
4) Для такого деплоя еще бы посоветовал посмотреть в сторону ansible
5) Вместо того чтобы использовать golang:latest можно от него создать свой образ с уже установленными либами, будет намного быстрее собираться
2) внутри раннера уже доступно содержимое репозитория, только артефакты (производные сборки полученные уже внутри стейджа) нужно копировать между стейджами
3) Ключ безопаснее пароля хотя бы тем, что состоит из двух частей и потеряв половину ключа (открытый ключ) злоумышленник сможет только шифровать сообщения, но не расшифровывать. Ключ нужно сгенерировать один раз на сервере и в CI передавать только публичный ключ, а приватный должен храниться на сервере.
4) Для такого деплоя еще бы посоветовал посмотреть в сторону ansible
5) Вместо того чтобы использовать golang:latest можно от него создать свой образ с уже установленными либами, будет намного быстрее собираться
1) Понял, спасибо попробую.
2) В комментарии выше тоже указали на это, попробую.
3) Спасибо, понял этот момент.
4) Ну мне тут конкретно гитлаб нужен был.
5) Хм, а как это сделать? Можете поделиться ссылкой?
2) В комментарии выше тоже указали на это, попробую.
3) Спасибо, понял этот момент.
4) Ну мне тут конкретно гитлаб нужен был.
5) Хм, а как это сделать? Можете поделиться ссылкой?
4) я про гитлаб и говорю, их можно совмещать. Просто при старте стейджа не руками запускать все, а запускать плейбук в котором все описано уже.
5) docs.gitlab.com/ee/ci/docker/using_docker_images.html. Предварительно нужно создать свой образ, например если бы нужен был libvips для сборки можно было бы что то вроед этого сделать
5) docs.gitlab.com/ee/ci/docker/using_docker_images.html. Предварительно нужно создать свой образ, например если бы нужен был libvips для сборки можно было бы что то вроед этого сделать
FROM golang:latest
RUN apt-get -qq update && apt-get install -y --no-install-recommends libvips-dev -qq
3) Ровно наоборот же, не? Приватный ключ клиента должен храниться только у клиента (в роли которого в данном случае CI)
Добавлю пример как легко сделать rpm/deb пакеты с использованием утилы fpm: github.com/stepin/udp-sniffer/blob/master/wercker.yml
Сайт утилы: github.com/jordansissel/fpm
Сайт утилы: github.com/jordansissel/fpm
Я бы все-таки загнал бы зависимости в /vendor. А-то еще сломают что-нибудь.
я вот про это.
- go get github.com/gorilla/mux
- go get github.com/gorilla/websocket
я вот про это.
Sign up to leave a comment.
Как настроить деплой web-приложения на Go для Gitlab на VDS