Установка программы из git

2012-05-17 в 21:25, admin , рубрики: puppet, rpm, yum, системное администрирование, метки: puppet, rpm, yum

Недавно появилась необходимость автоматизировать внедрение приложений из GIT на сервера.

В данной статье я решил описать свой опыт внедрения.

Поступило интересное задание по установке/обновлению приложения на серверах компании имея следующие данные:
* Приложение расположено в GIT
* Версия приложения можно узнать командой «git tag»
* Список серверов и путь где должно находиться приложение

Поскольку исторически так сложилось, что в компании используется RPM-based OS, то, IMHO, в данном случае наиболее правильным решением было реализовать упаковку приложения в RPM-пакет с последующим распространением его через puppet. Соответственно puppet устанавливает ПО и накатывает необходимый конфигурационный файл по шаблону.

Установка и настройка Git в Windows 10

Процесс настройки системы:

• Настройка yum-репозитория
• Установка и настройка nginx
• Скрипт автоматического build с размещением его в yum-репозиторий
• Автоматическая проверка обновлений и привязка к созданию build
• Настройка puppet

Настройка yum-репозитория

Тут оказалось всё просто. Поскольку мы собираемся использовать внутренний yum-репозиторий с доступом только с наших серверов, то подписывать его PGP/GPG-ключами нет необходимости.

Создаём папку где будут располагаться наши RPM-пакеты и создаём пастой репозиторий:

# yum install createrepo # mkdir -p /storage/v0.repo/6/x86_64/RPMS/ # ln -s /storage/v0.repo/6 /storage/v0.repo/6.2 # createrepo /storage/v0.repo/6/x86_64
[v0] name=v0 Yum Repo baseurl=http://v0.example.com/$releasever/$basearch/ enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/v0.key

По команде «# yum repolist» видим в списке наш репозиторий:

repo id repo name status v0 v0 Yum Repo 7

Установка и настройка nginx

Установка проста: «yum install nginx»

В конфигурационный файл nginx, в секцию http, добавляем строку: «include /etc/nginx/vhosts/*.conf;»

server < listen 80; server_name v0.example.com; autoindex on; root /storage/v0.repo; # ограничим доступ к репозиторию allow 62.152.38.0/24; allow 89.17.37.102; deny all; >

Запустим nginx и пропишем его в стартовых скриптах:

# /etc/init.d/nginx start # chkconfig nginx on

Скрипт автоматического build с размещением его в yum-репозиторий

Для начала устанавливаем необходимые пакеты:
yum install rpmdevtools

Привожу сам скрипт с комментами: /home/build_user/recordsapp_build.sh

Проверяем:
«$ yum —disablerepo=* —enablerepo=v0 info recordsapp» — покажет последнюю версию приложения
«$ yum —disablerepo=* —enablerepo=v0 provides recordsapp» — покажет все версии приложения, находящиеся в репозитории (может понадобиться при поддержке версионности: откаты на предыдущую версию и т.п.)

Изучение GitHub в одном видео уроке за 15 минут!

recordsapp-1.1-av.noarch : recordsapp. . Owner Repo : v0 Matched from:

Автоматическая проверка обновлений и привязка к созданию build

В данном разделе необходимо отметить, что получить версию приложения из GIT можно разными способами. Также можно по-разному и проверять обновления.

Чтобы разработчики сами могли «выкатывать» приложение, была составлена договорённость по получению версий через ‘git tag’

Скрипт проверки версии «~/.build_recordsapp/check.sh»:

Настройка puppet

Не буду описывать детальную настроку puppet — этого добра полно в поисковиках.

Куда писать версию приложения?
Поскольку я не уверен, как правильно надо делать… Слишком гибок в настройках Puppet. Можно в манифест отдельной ноды, можно в общий манифест, можно в темплейт. Ещё не совсем понял идеологию Паппета.
Представляю как это у меня реализовано на момент окончания тестирования:

#. import «hosts/v0.example.com.pp» import «hosts/v7.example.com.pp» #.
node «v0.example.com» < #. Сервер 1 — с указанием конкретной версии релиза приложения $recordsapp_ip = ‘127.0.0.113’ $recordsapp_ver = ‘1.4-av’ class < «recordsapp_hard»: recordsapp_hard_template =>»default», > >
node «v0.example.com» < #. dev-сервер с указанием последней версии для тестов приложения $recordsapp_ip = ‘127.0.0.117’ $recordsapp_ver = ‘latest’ class < «recordsapp_hard»: recordsapp_hard_template =>»default», > >
class recordsapp_hard ( $recordsapp_hard_template = «default» ) < class < ‘yum_v0::default’: yum_v0_template =>»default» > package < «recordsapp»: ensure =>$recordsapp_ver, > file < «/var/www/recordsapp»: ensure =>directory, recurse => true, owner => «httpd», group => «httpd», # mode => «755», > file < «/var/www/recordsapp/panel/tmp»: ensure =>directory, owner => «httpd», group => «httpd», mode => «0755», > file < «/var/www/recordsapp/config/env.php»: owner =>»httpd», group => «httpd», mode => «0644», content => template(«recordsapp_hard/$recordsapp_hard_template/env.php.erb»), > file < «/var/www/recordsapp/config/envs/prod.php»: owner =>»httpd», group => «httpd», mode => «0644», content => template(«recordsapp_hard/$recordsapp_hard_template/prod.php.erb»), > exec < «recordsapp-chmod-fix»: path =>[«/usr/bin», «/usr/sbin»], command => ‘find /var/www/recordsapp -exec chmod 0644 <> ; ; find /var/www/recordsapp -type d -exec chmod 0755 <> ;’, refreshonly => true, > >
# . тут настройки приложения
# . и тут настройки приложения #. define(«SELFIP», «»); #.

В результате мы получаем достаточно гибкую систему управления версиями.
На dev-серверах мы имеем последний релиз приложения без участия системного администратора. Разработчик может сам развернуть приложение на тестовом сервере обновив tag в git, а на сервера production устанавливается конкретный оттестированный релиз теми же средствами, но с указанием конкретного номера версии в манифесте puppet.

Источник: www.pvsm.ru

Полуавтоматический деплой приложения из GIT-репозитория

На дворе не 2005 год, и уже давно пора перестать заливать обновления сайта архивами или отдельными файлами через FTP. Как же доставлять обновления?

Современный подход к развёртыванию веб-приложения подразумевает использование Docker’а вкупе с Kubernetes, а тестирование и сборка приложения перед этим происходит в пайплайнах (pipeline) какой-нибудь системы непрерывной интеграции ( CI ) .

Но зачем все эти ресурсоёмкие сложности, если у Вас простой сайт на обычном хостинге, на котором поддержка докера не предусмотрена?

В основе предлагаемого метода лежит использование команды git worktree, дающей возможность работать с несколькими ветками git- репозитория в отдельных папках. Также подразумевается, что кодовая база вашего проекта уже давно ютится в git-репозитории.

Почему git worktree?

Если вы привычным образом склонируете репозиторий в public_html , то рискуете оставить папку с именем .git общедоступной (а это исходный код вашего приложения). На неё придётся прописывать правила в .htaccess или прибегать к иным костылям. В любом случае это небезопасный путь.

С git worktree клон репозитория может находится в укромном местечке, а в отделённой ветке будет файл с именем .git, в котором будет указан только путь до клона.

Кроме того, имея всего один клон репозитория, вы можете выделить из него разные ветки на несколько сайтов. Например, ветка test на тестовую версию сайта, а ветка production на боев ую версию .

Настройка хостинга и первичная установка приложения

Папка bin

Этот шаг необязательный, но я рекомендую первым делом создать папку bin в корне, куда будут помещены исполняемые файлы, и добавить её в переменную окружения PATH. Вводим в консоль:

mkdir $HOME/bin export PATH=$HOME/bin:$PATH

В корневой папке вашего профиля следует создать файл с именем .bash_profile с содержимым:

export PATH=$HOME/bin:$PATH

Вы можете сделать это с помощью следующей консольной команды:

echo «export PATH=$HOME/bin:$PATH» > $HOME/.bash_profile

Содержимое .bash_profile будет исполняться SSH- клиентом по умолчанию при подключении.

PHP

Если в своём проекте вы используете PHP , то учтите, что по умолчанию в консоли обычно используется PHP 5.3 (введите php — version , чтобы узнать версию). Для удобства использования в консоли PHP той версии, которая вам нужна, добавьте в папку bin ссылку. На примере PHP 7.2:

cd $HOME/bin; ln /opt/php7.2/bin/php php -s

Теперь php —version вернёт PHP 7.2.15 (примечание: минорная версия может отличаться).

Также разместите в папке bin последнюю версию Composer.

Важно: не забывайте о правах на чтение/запуск исполняемых файлов в папке bin.

Сертификаты

Если ваш проект находится в закрытом git- репозитории, то хосту понадобятся права доступа.

Можно использовать логин и пароль от учётной записи с правами, но мы поступим правильно и сгенерируем Deploy key (ключ, дающий доступ к репозиторию только на чтение).

В консоли пишем:

ssh-keygen -t rsa -f id_rsa

Для каждого сервера (gitlab, bitbucket, github. ) можно сгенерировать свой ключ, меняя значение id_rsa параметра -f.

В домашней папке появится папка с именем .ssh, в которой будут находиться сгенерированные приватные и публичные ключи. Создадим файл ~/.ssh/config со следующим содержимым:

Для gitlab:

Host gitlab.com RSAAuthentication yes IdentityFile ~/.ssh/id_rsa

Для bitbucket:

Host bitbucket.org IdentityFile ~/.ssh/id_rsa

Для разных хостов записи с одинаковыми или разными ключами можно совместить в одном файле. Пример:Публичный ключ (содержимое файла id_rsa.pub) необходимо добавить в список ключей развёртывания (Deploy Keys) репозитория.Форма для добавления ключа развёртывания в GitLab

GIT

На многих хостингах рунета по сей день крутится древний C entos с версией git 1.8.3. Такая старая версия git’a абсолютно нам не подходит. Команда git worktree появилась ещё в 2015 году в git 2.5, а в git 2.7 значительно расширилась по функционалу.

Но не беспокойтесь, на машинах T imeweb предустановлен git 2.7.4 .

Подготовим папку ~/git для размещения в ней клонов git-репозиториев и перейдём в неё:

mkdir $HOME/git cd $HOME/git

Клонируем репозиторий project-name в папку project-dir:

Перед выполнением команды замените путь до git- репозитория и имена ветки и проекта на свои.

где «master» – имя ветки, на которую будет переключен клон по умолчанию (если не указывать, то будет выбрана «основная ветка»).

ВАЖНО: следует указать ту ветку, которая не будет участвовать в разворачиваемых приложениях, т.к. дерево worktree нельзя создать из активной ветки. Например, если у вас есть ветки master, test, production, то следует выбрать master, а test и production будут вскоре развёрнуты.

Как и на многих хостингах, в T imeweb применяется практика с использованием папки public_html в качестве корневой папки сайта (веб-папки проекта). Если у вас мультисайтовый аккаунт (более одного сайта на хосте), то и папок public_html несколько. Например:

• ~/www-project-name/public_html — для боевого приложения,
• ~/www-test-project-name/public_html — для тестов.

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

Обычно веб-папка проекта не всегда совпадает с корневой папкой приложения: в веб-папке принято размещать только публичные файлы — JS- скрипты, картинки, стили, шрифты; а также файл скрипта для инициализации приложения. Весь рабочий код остаётся вне веб-папки. Эта практика приводит к единственному решению — public_html должна быть ссылкой на веб-папку проекта. Сам проект можно разместить рядом, в папке branch.

Развернём ветку production. На этом этапе уже пора добавить в админской панели свой сайт www-project-name и вместе с тем создадутся папки ~/www-project-name/public_html. Папку public_html со страницей-заглушкой нужно сразу удалить. Теперь создаём worktree в папке ~/www-project-name/branch:

cd $HOME/git/project-dir git worktree add $HOME/www-project-name/branch production

Создаём символьную ссылку веб-папки на месте папки public_html , которую вы ранее удалили . В моём примере веб-папка является папкой web в корне проекта, у вас она может отличаться.

ln -s $HOME/www-project-name/branch/web $HOME/www-project-name/public_html

Поскольку в моём приложении есть и ветка test , то таким же образом я разверну и её:

cd $HOME/git/project-dir git worktree add $HOME/www-test-project-name/branch test ln -s $HOME/www-test-project-name/branch/web $HOME/www-test-project-name/public_html

Установка приложения

На текущем этапе все файлы нужн ых веток репозитория проекта размещены в соответствующих каталогах:

~/www-project-name/branch – production- ветка

~/www- test- project-name/branch – test- ветка

Осталось установить и настроить приложение. Переходим в корневую папку приложения:

cd $HOME/www-project-name/branch

Настройте конфиг урационные файлы, которые, кстати, должны быть предварительно добавлены в .gitignore.

Если вы используете пакетные менеджеры, то подтяните необходимые пакеты. Применительно к Composer :

composer install —no-dev

Установите само приложение. Например, если это Yii2:

php yii init php yii migrate
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Обновление

Приложение развёрнуто.

Осталось настроить обновление приложения — вы ведь будете его поддерживать?

Для этого в папке bin создадим скрипт, который будет подгружать изменения из git-репозитория и применять их. На моём сервере это будет файл ~/bin/hi (с правами на запуск):

~/bin/hi

Содержимое файла в моём случае:

echo «Привет!» echo «»;echo «Синхронизация репозитория»; cd $HOME/git/project-dir;git fetch; echo «»;echo «Обновление production»; # переход к файлам приложения cd $HOME/www-project-name/branch; # сброс и подгрузка изменений git reset —hard;git pull origin production; # установка нужных версий зависимостей /opt/php7.2/bin/php $HOME/bin/composer install —no-dev; # к php нужно прописывать полные пути! # моё приложение поддерживает миграции с бэкапами /opt/php7.2/bin/php core migrate/up —all —backup; # для Yii2 это будет . php yii migrate —interactive=0 echo «»;echo «Обновление test»; cd $HOME/www-test-project-name/branch; git reset —hard;git pull origin test; /opt/php7.2/bin/php $HOME/bin/composer install —no-dev; /opt/php7.2/bin/php core migrate/up —all;

Таким образом, я буду заходить на сервер и здороваться с ним командой hi, а он поздоровается со мной, подгрузит с гита и установит обновления моего приложения .

Такой способ предоставляет обновление в полуавтоматическом режиме. Однако можно настроить и полностью автоматическое обновление приложений, например, сразу после пуша изменений в соответствующую ветку. В этом вам может помочь, например, опция web-push в настройках удалённого репозитория .

Примечание:

Вы, наверно, заметили, что перед подтягиванием обновлений вызывается команда

git reset —hard

Поэтому пользовательские файлы и файлы конфигурации должны быть помещены в .gitignore, чтобы git их не удалил при обновлении.

Источник: timeweb.com

Установка программы из git

Введите свои данные: электронную почту; пароль (рекомендации по созданию надежного пароля); имя, которое будет использоваться на GitHub и подтверждение на рассылку.

После регистрации, на указанную почту, придет письмо: откройте в нем ссылку для подтверждения своего электронного адреса.

5.2. Создание репозитория
Следующим шагом является создание на GitHub нового репозитория.

Репозиторий — это просто хранилище для чего угодно. В нашем случае, мы будем хранить в нем код. Репозиториев можно создать неограниченное количество под любой проект. Например, сейчас мы создадим хранилище под названием startjava2 (вам цифру 2 писать не нужно). А в будущем еще несколько под разными названиями: basejava, topjava — в них будет храниться код, связанный с этими проектами.

Чтобы создать новый репозиторий, нажмите на сайте GitHub в правом верхнем углу + и выберите New repository.

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

Нажав Create repository, вас перекинет на страницу со ссылкой на созданный репозиторий и набором стандартных команд, которыми мы воспользуемся в следующей статье.

Репозиторий создан!
6. Способы авторизации

Доступ к репозиториям на GitHub из командной строки можно получить двумя способами: по протоколу HTTPS или SSH.

С 13 августа 2021 г. GitHub отменил использование паролей для аутентификации из командной строки с помощью Git в пользу токенов персонального доступа (Personal access tokens, PAT). Эти шаги были сделаны с целью повышения безопасности пользователей.

6.1. Токен персонального доступа и HTTPS
Для доступа (авторизации) к GitHub по протоколу HTTPS необходимо создать PAT.
Преимущества PAT перед паролями:

• возможность генерации токена для каждого устройства, с которого необходимо получать доступ к репозиторию на GitHub
• возможность настройки ограничений для каждого токена при работе с GitHub
• возможность аннулирования токена для конкретного устройства
• возможность ограничить срок действия токена

6.1.1. Создание токена
Для создания токена необходимо выполнить следующие шаги:
Авторизуйтесь на github.com, а затем нажмите на фотографию своего профиля и выберите Settings.
В левой панели нажмите пункт Developer settings
Так же слева нажмите Personal access tokens, а затем кнопку Generate new token
Дайте название (краткое описание) создаваемому токену, а также срок его действия.

Выберите действия, которые будет разрешать данный токен. Чтобы использовать его для доступа к репозиториям из командной строки, отметьте пункты, где присутствует слово repo. А затем нажмите Generate token.

Скопируйте полученный токен в буфер обмена для последующего использования
Предупреждение: относитесь к своим токенам как к паролям, и держите их в секрете.

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

При запросе аутентификации, вам нужно будет ввести:

Username: ваш email Password: ваш токен

В Windows Git для хранения учетных данных пользователей поставляется с диспетчером учетных данных (Git Credential Manager for Windows, GCM). Мы с ним встречались во время установки Git. Он по умолчанию сохраняет учетные данные, что позволяет не вводить их все время.

Для просмотра его конфигурации введите следующую команду:

git config credential.helper

Если вы используете Git версии 2.29 или более позднюю, то в консоли отобразится надпись manager-core. Для более ранних версий credential.helper имеет значение manager.

Если команда выдаст что-то отличное от manager-core, то введите:

git config —global credential.helper manager-core
7. Доступ через SSH

Если среди начинающих про HTTPS знают все, то про SSH многие даже и не слышали. Исправим это, проведя вводный ликбез, а заодно и узнаем про доступ к GitHub через данный протокол.

SSH (Secure SHell, «безопасная оболочка») — это сетевой протокол, обеспечивающий шифрование передаваемых данных, а также защищенный доступ к удаленному серверу.

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

В терминале пишем команду ssh-keygen (после все время жмем Enter, ничего не вводим).

В итоге по адресу C:UsersИмя_пользователя.ssh будет создано два файла: id_rsa (приватный — никому его не показывайте) и id_rsa.pub (открытый — можете показывать кому угодно).

Чтобы проще запомнить назначение ключей, их можно представить, как замок (открытый) и ключ к замку (закрытый). Замок без ключа не открыть, а при этом замок может видеть кто угодно.

Данные ключи являются взаимозависимыми: зашифровав информацию одним ключом, расшифровать ее можно только другим. Например, если вы зашифровали pdf-документ публичным ключом (ставите на него замок), то открыть и прочитать его сможете только вы, т. к. только у вас есть закрытый ключ. Так же это работает и в обратную сторону: если вы зашифруете письмо приватным ключом, то расшифровать его можно только вашим публичным ключом.

Это также означает, что так как ваш публичный ключ может распространяться открыто, то любой, кто им обладает (коллега), сможет открыть зашифрованный документ. Но в этом нет опасности, т. к. это лишь гарантирует, что документ был зашифрован именно вами. По такому принципу работает цифровая подпись.

Источник: topjava.ru