Меню Рубрики

Git2go build on windows

Git для начинающих. Часть 2. Установка Git

Для того, чтобы начать работать с системой контроля версий Git ее необходимо предварительно установить. Рассмотрим варианты установки этой VCS под MS Windows и Linux.

Установка Git под Windows

Для установки Git под Windows необходимо предварительно скачать дистрибутив. Для этого перейдите на страницу https://git-scm.com/

Если вы зашли из под операционной системы (ОС) Windows, главная страница сайта будет выглядеть примерно так, как показано на рисунке ниже. Для других ОС отличие будет заключаться в том, что изменится область для скачивания дистрибутива (см. правый нижний угол).

Для того чтобы скачать Git нужно нажать на кнопку Downloads for Windows, расположенную в правой части окна.

Процесс дальнейшей установки Git выглядит так.

1. Запустить установочный файл

2. Ознакомиться, если есть желание, с лицензионным соглашением и нажать на кнопку Next

3. Выбрать компоненты, которые следует установить

4. Указать способ использования Git

В этом окне доступны три возможных варианта:

  • Use Git from Git Bash only

Переменная PATH не модифицируется и работа с Git возможна только через специализированную оболочку, которая называется Git Bash.

  • Use Git from the Windows Command Prompt

В этом случае происходит минимальная модификация переменной окружения PATH, которая позволит работать с Git через командную стоку Windows. Работа через Git Bash также возможна.

  • Use Git and optional Unix tools from the Windows Command Prompt

В переменную PATH вносится значительное количество модификаций, которые позволят, в рамках командной строки Windows, использовать как Git так и утилиты Unix, которые поставляются вместе с дистрибутивом Git.

Наша рекомендация: опция Use Git from the Windows Command Prompt.

5. Настройка правил окончания строки

Существует два варианта формирования конца строки в текстовых файлах – это Windows стиль и Unix стиль. Данное окно позволяет выбрать одну из опций, определяющих правило формирования окончания строки:

  • Checkout Windows-style, commit Unix-style line endings

Checkout (операция извлечения документа из хранилища и создания рабочей копии) производится в Windows стиле, а commit (операция отправки изменений в репозиторий) в Unix стиле.

  • Checkout as-is, commit Unix-style line endigns

Checkout производится в том формате, в котором данные хранятся в репозитории, а commit осуществляется в Unix стиле.

  • Checkout as-is, commit as-is

Checkout и commit производятся без дополительных преобразований.

Наша рекомендация: опция Checkout Windows-style, commit Unix-style line endings.

6. Выбор эмулятора терминала, который будет использован с Git Bash

Возможен выбор из двух вариантов:

  • Use MinTTY (the defaul terminal of MSYS2)

Git Bash будет использовать в качестве эмулятора терминала MinTTY.

  • Use Windows’ default console window

Git будет использовать Windows консоль (“cmd.exe”).

Наша рекомендация: опция Use MinTTY (the defaul terminal of MSYS2).

7. Настройка дополнительных параметров

Доступны следующие параметры:

  • Enable file system caching

Включение операции кэширования при работе с файлами. Эта опция позволит значительно повысить производительность.

  • Enable Git Credential Manager

Предоставляет возможность работы с защищенным хранилищем.

  • Enable symbolic links

Активирует работу с символьными ссылками.

Наша рекомендация: опции Enable file system caching и Enable Git Credential Manager.

8. Завершение установки

После нажатия на кнопку Install будет произведена установка Git на Windows, по окончании установки пользователь получит соответствующее сообщение.

Установка Git под Linux

Для установки Git под Linux, также необходимо зайти на сайт https://git-scm.com/ и перейти в раздел Downloads. В зависимости от используемой вами версии операционной системы Linux необходимо выбрать тот или иной способ установки Git.

Solaris 11 Express

Рекомендуем классный курс по git от GeekBrains , перейдите по ссылке и найдите в разделе “Курсы” курс “Git. Быстрый старт” . Это бесплатный видеокурс, зарегистрируйтесь и начинайте получать новые знания.

Источник

Как настроить деплой web-приложения на Go для Gitlab на VDS

Предисловие

Эта статья является результатом недельного поиска весьма разрозненной информации о том, как же настроить деплой web-сервиса на Go. Не на Heroku, не на Docker, не на Digital Ocean, а просто на старомодный VDS с CentOS 7×64. Почему-то в сети нет этой информации, а большинство туториалов начинаются с того, как настроить билд, и заканчиваются запуском тестов.

Сразу предупрежу, что впервые настраивал CI/CD процесс, так что это статья от новичка новичку.

Наверняка здесь многое можно будет поправить, так что любые замечания с удовольствием приму в комментариях и постараюсь обновить изменения как можно скорее. Так же, возможно, что такая статья уже есть, и я просто ужасно пользуюсь поисковиком. Тогда дайте, пожалуйста, ссылку на неё, и в этом случае, я удалю статью и пойду посыпать голову пеплом.

Исходные данные

  • VDS сервер
  • ОС: CentOS 7×64
  • Проект на go со следующей структурой:

Настройка сервера: Создаем сервис

Сначала создадим сервис для нашего приложения. В CentOS 7 это делается довольно просто. Нужно написать вот такой скрипт в файле под названием serviceName.service:

Сам скрипт необходимо положить в папку etc/systemd/system/

Настройка SSH

На сервере запускаем команду:

Enter passphrase (empty for no passphrase)

не вводим пароль, просто нажимаем на Enter.

В папке /etc/ssh/ сгенерируется два файла:

  1. hmp.key — приватный ключ
  2. hmp.key.pub — публичный ключ

Нам нужен приватный ключ. Просматриваем его содержимое с помощью команды:

Оно будет выглядеть примерно так:

Все полностью копируем себе в буфер обмена

ВНИМАНИЕ! — не только сам ключ, но и
—–BEGIN RSA PRIVATE KEY—– и —–END RSA PRIVATE KEY—–

Настройка Gitlab

Сначала заполним данные, важные для деполя, (имя пользователя, пароль и.т.п.).
Даже если Ваш репозиторий публичный, они останутся закрытыми.

В Gitlab в репозитории заходим в Settings –> CI/CD –> Variables. Создаем там следующие переменные:

  • SSH_PRIVATE_KEY — сюда вставляем значение, скопированное в предыдущем пункте
  • USER_PASS — пароль пользователя, из под которого будет запускаться приложение
  • USER — имя пользователя, из под которого будет запускаться приложение
  • HOST — адрес вашего VDS
  • TARGET_DIR_ON_HOST — целевая папка, в которой будет находиться ваш сервис в моем примере это /username/service/
  • SERVICE_NAME — имя сервиса
  • GROUP_NAME — имя вашего пользователя на Gitlab
  • REPOSITORY_NAME — название вашего репозитория

Добавляем в репозиторий файл .gitlab-ci.yml со следующим содержимым:

После донастройки, этот скрипт пушим в репозиторий и у нас оказывается готовая сборка и деплой. На этом все!

Надеюсь статья была полезной. По любым вопросам и замечаниям с радостью отвечу в комментариях!

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Вышел релиз GitLab 13.3 с полным покрытием фаззинг-тестированием и матрицей сборки для CI/CD

«Ну, покати!» или CI/CD мобильных приложений на основе контракта

Лучшие практики CI/CD с Kubernetes и GitLab (обзор и видео доклада)

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 22

Эм, я правильно понимаю, что отключены чуть ли не все средства безопасности SSH?

Ещё я не понял, зачем применяются одновременно SSH_PRIVATE_KEY и USER_PASS

По первому вопросу, если честно не отвечу, поскольку не знаю, какие есть и как их включить, если подскажете, то я попробую решить этот вопрос и обновить статью.

По второму вопросу. Там смотрите есть два сервера — первый это тот который находится в 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, и на этот вопрос какие-нибудь спецы могут ответить лучше чем я (если они тут есть)

Я go не юзаю, я питонист. Но у меня такое прекрасно работало, и я не думаю, что в go (и в любом другом языке) это должно как-то принципиально отличаться

В этом моём gitlab-ci.yml pip install -e . — установка проекта из текущего каталога, где текущим каталогом является как раз склонированный репозиторий

(правда, стоит заметить, что у меня был свой локалхостовый гитлаб, может его CI чем-то отличается от обычного гитлаба, не знаю)

Стоп стоп стоп
Создание приватного ключа на сервере, кто же так делает?

Cуть CI/CD для абстрактного проекта такова:
1. вы пушите код в репозиторий
2. сервер сборок (CI-сервер) (либо по триггеру от шага 1, либо проверяет сам наличие изменений и если они есть) клонирует репозиторий (точнее даёт команду нужному «агенту сборки» ) и запускает некие этапы сборки (обычно это `build — test — deploy`), которые указаные в конфигурации
3. на этапах могут появляться артефакты сборки, которые могут быть доступны в веб-интерфейсе и передаются между этапами (например, после build появляется некий (раз у вас CentOS) RPM-пакет, который на этапе deploy, устанавливается на целевые системы.

Источник


Adblock
detector