​​Хочу посоветовать всем системным администраторам, кто это еще не сделал, обратить пристальное внимание на git. Сам я давно пользуюсь этой системой контроля версий, но только недавно дошел до того, что стал там хранить практически все текстовые данные.

Чистил свою тестовую лабу и удалил несколько виртуалок. И только потом вспомнил, что на одной из них были нужные скрипты, на написание которых ушло прилично времени. Все репозитории проверил, нигде не нашел копий. Их просто не было. Пришлось потратить несколько часов на восстановление.

Теперь всегда, прежде чем начать писать какой-то скрипт или более ли менее большой конфиг, создаю репозиторий под это дело и все пушу туда. Я обычно использую облачный gitlab и свой локальный для приватных данных. Gitlab - мое личное предпочтение. Вы можете использовать любой бесплатный сервис. Их сейчас полно развелось.

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

#git

Если вы по какой-то причине до сих пор не изучили Git 😱, то можете попробовать изучить его с помощью бесплатного курса - https://ru.hexlet.io/courses/intro_to_git. Я там зарегистрировался и посмотрел уроки. Понравилось, как всё устроено. Никакие персональные данные платформа не вытягивает. Регистрация по почте. Немного на Stepik похоже.

Есть несколько бесплатных курсов для системных администраторов. Помимо Git может быть полезно пройти Основы командной строки Linux и Основы языка Python.

Отмечаю, что это не реклама данной платформы. У меня никто ее не заказывал. Я просто немного на нее посмотрел и мне показалась интересной. Очень много всевозможных курсов, в основном для программистов, но есть кое-что по devops и системному администрированию. При этом месячная подписка стоит 3900. Сравните это с другими курсами, которые у меня рекламируются.

Можете просто купить доступ на месяц и забрать себе все интересующие вас курсы, чтобы спокойно изучить потом. Очень доступно. Если есть реальное желание чему-то научиться, то можно это без особых проблем и финансовых затрат сделать.

#обучение #git

​​Gitea - легковесная Open Source-система для управления Git-репозиториями, которую можно развернуть на своем сервере. Обычно, когда вспоминают про self-hosted git репозиторий, на ум приходят Gitlab, Bitbucket. Я почти везде вижу либо Gitlab, либо аккаунт в Github. Хотя зачастую, весь функционал, что предлагают эти продукты, не нужен.

В то же время Gitea более проста в установке, настройке, бэкапе. Может работать даже на Raspberry Pi. При этом закрывает все основные потребности в хранении кода. Очень многим командам разработчиков или девопсов будет её достаточно. Особенно если уже есть какой-то инструмент для CI/CD.

В самом простом случае Gitea может использовать базу данных SQLite. Поставить и потыкать, как обычно, проще всего в Docker. Не буду сюда копировать простыню docker-compose файла. Посмотрите его в документации. При этом присутствует дистрибутив под Windows. Gitea можно поставить даже на Windows 10.

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

Сайт - https://gitea.io
Документация - https://docs.gitea.io
Исходники - https://github.com/go-gitea/gitea
Установка на Windows - https://www.youtube.com/watch?v=_Wu1MjrsGUc

#git #selfhosted

​​Необычный софт посмотрел, аналогов которого раньше не видел. Git репозиторий с просмотром содержимого через консоль - Soft Serve (странное название 🤔). Есть пакеты под все системы. Также можно в докере запустить. Я пробовал и так, и так.

https://github.com/charmbracelet/soft-serve

Ставим на rpm-based:
# rpm -ivh https://github.com/charmbracelet/soft-serve/releases/download/v0.1.2/soft-serve_0.1.2_linux_amd64.rpm
Запускаем:
# soft
У вас должен стоять git, чтобы всё заработало. Вот готовая команда для запуска в докере.

По умолчанию Soft Serve слушает все интерфейсы, работает на порту 23231. Для подключения нужно использовать приватный ключ, который он положит в директорию ~/.ssh, название - soft_serve_server_ed25519.
# ssh localhost -p 23231 -i ~/.ssh/soft_serve_server_ed25519

Окажетесь в TUI. У вас там будет пусто, так как репозитории не настроены. Их через конфиг надо добавлять. Пример есть на github. Причём для настройки надо склонировать дефолтную репу config и запушить изменения настроек.

Посмотреть, как всё это будет работать в настроенном виде, можно в публичном репозитории по адресу git.charm.sh. Подключение по ssh, пароль пустой (без пароля).
# ssh git.charm.sh

Я не знаю, где подобное может на практике пригодиться. Чисто по приколу для своих личных локальных репозиториев. Необычно просматривать всё через консоль. Работает как обычный git сервер. Создаёте, клонируете, пушите код. Через TUI только просмотр.

#git

​​Вы когда-нибудь публиковали в паблик свои пароли по ошибке? Я сам ни разу не замечал за собой такое, но от разработчиков видел подобное много раз. Один знакомый умудрился в публичные репы github выложить Dockerfiles нод криптовалют со своими кредами.

Есть достаточно известный продукт gitguardian (https://gitguardian.com) для автоматического сканирования репозиториев и обнаружения там приватных данных: токенов, паролей, сертификатов. Настраивается он просто, так как доступна готовая интеграция с популярными сервисами. А сам он работает по модели SaaS или self-hosted (только за деньги).

Есть бесплатная версия для небольших команд. У неё одно простое ограничение - не более 25 разработчиков на проект. Разработчиком в данном контексте является активный контрибьютор, который сделал хотя бы один коммит в течении последних 90 дней. Ограничение достаточно лояльное, так что бесплатная версия подойдёт для широкого круга небольших команд.

#git #devops #security #бесплатно

​​Познакомился с отечественным сервисом git, условным аналогом github - https://gitflic.ru. Зарегистрировался там и на всякий случай перенёс несколько своих основных личных репозиториев. Я их всегда хранил на gitlab, но последнее время стал регулярно копировать локально, опасаясь блокировки или ещё каких-нибудь диверсий.

Gitflic имеет бесплатный тарифный план, у которого одно ограничение - в приватном репозитории не может быть более 5-ти человек. Для одиночного использования считай что ограничений нет совсем.

Сразу видно, что проект очень молодой и ещё не факт, что взлетит, но пользоваться можно уже сейчас. Функционал небольшой, но лично мне кроме непосредственно git больше ничего не надо. Дизайн простой и лаконичный. Бонусом идёт хороший отклик и быстродействие в браузере. Думаю, это потому что нагрузки нет. Когда работаешь в браузере разница с gitlab огромная. Последний очень тормозной.

Надеюсь проект взлетит и наберёт популярность. Мне осталось придумать какой-нибудь наименее костыльный вариант для синхронизации трёх источников с кучей репозиториев - gitlab, gitflic, локальный ноут. У кого какие идеи, как это лучше организовать? Понятно, что можно просто скриптом забабахать, но может как-то по-другому можно?

#git #бесплатно #отечественное

​​Всем хорошо известен продукт Gitlab, который закрывает несколько базовых потребностей современной разработки: хранение кода, сборка и деплой, хранение образов. И всё это реализовано в единой платформе.

Обратной стороной этого удобства является высокие требования по железу, избыточный во многих случаях функционал, перегруженный, не слишком отзывчивый веб интерфейс.

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

Gitea - легковесная Open Source-система для управления Git-репозиториями, которую можно развернуть на своем сервере. Отличает её простота установки и настройки, низкие требования к производительности. В самом простом случае Gitea может использовать базу данных SQLite.

Drone CI - популярная система непрерывной интеграции, написанная на Go. Также отличается легковесностью (docker образ ~24Мб), простым синтаксисом yaml файлов для сборки. Легко интегрируется с любым git репозиторием и хранилищем docker образов. Отлично подходит для знакомства с ci/cd на основе docker контейнеров.

Docker Registry 2.0 - вариант локального registry от самой компании Docker. Тоже очень простой продукт с минимальными требованиями к железу. Размер docker контейнера, в котором он запускается 8Мб. При желании к нему можно установить веб интерфейс - docker-registry-ui.

Указанный набор программ связывается между собой в единую систему, обеспечивая базовый функционал по разработке и доставке софта на базе docker контейнеров. Drone CI расширяет функционал с помощью плагинов. Например, плагин для отправки уведомлений в telegram, запуска удалённых команд по ssh, выполнения webhook и т.д.

Если есть идеи, чем можно заменить одну из предложенных программ, предлагайте в комментариях. Я сделал акцент на легковесности и простоте установки, настройки.

Gitea - https://github.com/go-gitea/gitea
Drone - https://github.com/harness/drone
Registry 2.0 - https://hub.docker.com/_/registry

#docker #devops #git

​​Ранее я уже рассказывал про Gitea. Это легковесная Open Source-система для управления Git-репозиториями, которую можно развернуть на своем сервере. Её отличает простота установки и настройки, а так же возможность использования базы sqlite. Для небольших проектов этого достаточно, зато никаких хлопот с обслуживанием и бэкапами.

Попробовать Gitea можно, запустив в Docker. Я решил ещё раз написать про неё, потому что попробовал тему - Gitea Modern. С ней совсем другой вид и впечатление от веб интерфейса. Внешний вид приятнее и функциональнее.

Вот готовый docker-compose.yml для запуска с этой темой по умолчанию:

version: "3"

networks:
 gitea:
  external: false

services:
 server:
  image: gitea/gitea:1.16.8
  container_name: gitea
  environment:
   - USER_UID=1000
   - USER_GID=1000
   - GITEA_CUSTOM=/data/gitea
  restart: always
  networks:
   - gitea
  volumes:
   - ./gitea:/data
   - /etc/timezone:/etc/timezone:ro
   - /etc/localtime:/etc/localtime:ro
  ports:
   - "3000:3000"
   - "222:22"

Я добавил переменную GITEA_CUSTOM, а её содержимое попадает в volume, подключенный к ./gitea. Теперь надо сделать папку /data/gitea/public/css и положить туда файл темы theme-gitea-modern.css. Новую тему также надо добавить в конфиг /data/gitea/conf/app.ini. Добавляем в самый конец:
[ui]
THEMES = gitea,gitea-modern
DEFAULT_THEME = gitea-modern

Больше от дефолтной установки ничего не менял. Теперь можно запустить и оценить новый вид веб интерфейса.

#git #devops

​​Часто возникают ситуации, когда хочется вести контроль версий конфигурационных файлов в системе Linux. Это может быть актуально не только, когда сервером пользуются несколько человек, но и для единственного администратора. Простейший способ контроля версий - создание копии файла перед редактированием.

Я предлагаю автоматизировать эту процедуру и использовать систему контроля версий git для этих целей на примере ОС Debian или Ubuntu. Для любого другого дистрибутива всё настраивается аналогично.

Устанавливаем git:
# apt install git

Создаём файл конфигурации git:
# touch ~/.gitconfig
Добавляем информацию о пользователе:
[user]
name = root
email = root@debian11-websrv

Создадим репозиторий для конфигов и сразу переименуем его, чтобы потом не путать с другими:
# cd ~ && git init && mv .git system.git

Добавим в корень системы / информацию о том, где находится репозиторий:
# echo "gitdir: /root/system.git" > /.git

Устанавливаем права доступа:
# chmod 600 ~/.gitconfig
# chmod 600 /.git
# chmod 700 /root/system.git

Настраиваем с помощью списка exclude директории, за которыми будет следить git. Данном случае это /etc. Для этого добавляем в файл ~/system.git/info/exclude пару строк:
/*
!/etc

У нас всё готово. Делаем первый commit:
# cd ~
# git add -A && git commit -m 'Создание репозитория debian11-websrv'

Добавляем в системный cron выполнение задания с коммитом каждую минуту:
* * * * * root cd / && git add -A && git commit -m "Cron commit" > /dev/null

Теперь можно что-то изменить в конфигурации, дождаться коммита и проверить изменения. Например, добавьте пользователя:
# adduser user01

Посмотрите изменения:
# git log --follow -p /etc/passwd

Я показал пример, как это может быть настроено. При желании, можно добавить и другие директории. Например, /var/spool/cron/crontabs или /usr/local/etc. Последнее было очень актуально в Freebsd, но давно уже не вижу, чтобы там что-то полезное хранилось.

Дополнительно неплохо было бы хранить информацию об установленных пакетах. Все изменения отражаются в лог файле пакетного менеджера, но добавлять в git логи не очень хорошая идея. Удобнее было бы выгружать список пакетов с какой-то периодичностью в файл в /etc/ примерно так:
# rpm -qa > /etc/packages.list
# dpkg -l > /etc/packages.list

Статья по сути готовая инструкция, так что можно забрать в закладки. Если есть какие-то замечания, или более универсальное, удобное решение этой же задачи, делитесь в комментариях. Я знаю, что есть etckeeper, но мне кажется, для такой простой задачи, которую можно решить только с помощью git, нет смысла привлекать какой-то сторонний софт.

#linux #git

Простой и быстрый способ забэкапить свои репозитории из github или gitlab. Я не стал тут изобретать велосипед, а просто поискал информацию. Нашёл много всяких программ и утилит на различных языках программирования. Всё это отмёл, пока не нашёл простые bash скрипты. Для меня было очевидно, что для решения этой задачи достаточно bash и api указанных сервисов.

В итоге воспользовался вот этим репозиторием:
⇨ https://github.com/alexadam/repo-backup
Очень простое и рабочее решение.

Я всё своё храню в Gitlab. Сходил в настройки, выдал токен с разрешениями на чтение api и репозиториев. И использовал его в скрипте:

#!/bin/sh

dirname=gitlab-backup-$(date "+%Y-%m-%d-%H-%M-%S")
mkdir "$dirname"
cd $dirname

privateToken=YOUR_ACCESS_TOKEN
userName=YOUR_GITLAB_USERNAME

curl --header "Private-Token: $privateToken" \
"https://gitlab.com/api/v4/users/$userName/projects" \
| jq -r '.[] | .id, .name' \
| while IFS= read projectId; read projectName; do
curl --header "Private-Token: $privateToken" \
"https://gitlab.com/api/v4/projects/$projectId/repository/archive.zip" \
--output $projectName.zip
done

echo Done! All files downloaded here: $(pwd)

После запуска получаю директорию с датой в имени, где внутри все мои проекты, каждый в отдельном zip архиве. Просто и удобно. Для github решение аналогичное. Там просто апишка другая, но смысл такой же.

Я до этого git clone делал по списку. Подом думаю, что я ерундой страдаю. В итоге забрал себе этот скрипт, который работает в разы быстрее и проще.

#backup #git #devops

​​В рамках темы по синхронизации файлов расскажу про необычный инструмент на основе git - git-annex. Это система управления файлами без индексации содержимого. С помощью git индексируются только имена, пути файлов и хэш содержимого. Для использования необходимо понимание работы git. Эта система больше всего подойдёт для индивидуального или семейного хранения файлов в разных хранилищах.

Я не буду расписывать, как эта штука работает, так как она довольно заморочена, а сразу покажу на примере. Так будет понятнее. Программа есть под все популярные ОС, но под Windows всё ещё в бете, так что запускать лучше Linux версию в WSL. В Debian и Ubuntu ставим стандартно из базовой репы:
# apt install git-annex

Переходим в директорию /mnt/annex, где хранятся какие-то файлы и инициализируем там репозиторий, пометив его как server:
# git config --global user.email "root@serveradmin.ru"
# git config --global user.name "Serveradmin"
# git init .
# git annex init 'server'

Добавляем файлы в репу:
# git annex add .
# git commit -m "Добавил новые файлы"

Все файлы превратились в символьные ссылки, а их содержимое уехало .git/annex/objects.

Скопируем этот репозиторий на условный ноутбук, который будет периодически забирать нужные файлы с сервера и пушить туда какие-то свои новые или изменения старых. Для этого он должен ходить на сервер по SSH с аутентификацией по ключу.

На ноутбуке копируем репозиторий с сервера и сразу синхронизируем:
# git clone ssh://user@1.2.3.4/mnt/annex
# git annex init 'notebook'
# git annex sync

Мы получили на ноутбуке копию репозитория, но вместо файлов у нас битые ссылки. Так и должно быть. Если вы хотите синхронизировать все реальные файлы, то сделать это можно так:
# git annex get .
А если только один файл, то так:
# git annex get docker-iptables.sh

Когда у вас несколько устройств работают с репозиторием, то узнать, где физически находится файл можно так:
# git annex whereis file.txt
whereis file.txt (2 copies)
    01f4d93-480af476 -- server [origin]
    13f223a-e75b6a69 -- notebook [here]

Вернёмся на сервер и добавим в него информацию о ноуте:
# git remote add notebook ssh://user@4.3.2.1/mnt/annex
# git annex sync

Теперь репозитории знают друг о друге. На ноутбук он был клонирован с сервера, а на сервер мы вручную добавили ноутбук. Добавим новый файл в репозиторий с ноутбука:
# git annex add nout.txt
# git commit -m "add nout.txt"

Проверим его местонахождение:
# git annex whereis nout.txt
whereis nout.txt (1 copy) 
  637597c-3f54f8746 -- notebook [here]

Он только на ноутбуке. Идём на сервер, делаем там синхронизацию и поверяем местонахождение файла:
# git annex sync
# git annex get nout.txt
# git annex whereis nout.txt
whereis nout.txt (2 copies) 
  6307597c-3f54f5ff8746 -- [notebook]
   edeab032-7091559a6ca4 -- server [here]

Теперь он располагается в двух местах.

Надеюсь, у меня получилось хоть немного показать, как эта штука работает. У неё много настроек. Можно очень гибко указать какие файлы по весу, количеству копий, типу папок, имени, типу содержимого нужны в каждом репозитории. Есть преднастроенные группы: backup, archive, client, transfer. Например, можно принудительно скачивать все файлы при синхронизации:
# git annex sync --content

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

И не забываем, что у нас все преимущества git в виде версионирования. Более подробно о работе можно почитать в документации. На первый взгляд кажется, что система слишком сложная. Для тех, кто не знаком с git, да. Но я не раз видел восторженные отзывы о системе тех, кто в ней разобрался и активно пользуется.

⇨ Сайт / Обучалка

#git #fileserver

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

Простая команда, про которую я узнал случайно. Она объединяет добавление изменённых файлов и коммит. Удобно и пригодится всем:

# git commit -am "changed two files"

Заменяет:

# git add .
# git commit -m "changed two files"

Можно сразу алиас сделать, чтобы ещё упростить команду:

# git config --global alias.cam "commit -am" 
# git cam "changed two files"

Если регулярно используете git, то можно добавить в алиасы наиболее часто используемые команды. Status так точно можно добавить:

# git config --global alias.st status 
# git st

Если чего-то понаделали локально в репозитории, хотите сохранить эти изменения, но не хотите пушить их куда-то, то можно воспользоваться командой stash. Она удалит все изменения в файлах, но сохранит их отдельно, чтобы можно было вернуться к ним, если понадобится.

# git stash

Файлы вернулись в первоначальный вид, а все изменения сохранены отдельно. Если захотите вернуть их, то выполните:

# git stash pop

Все изменения вернулись в файлы. У stash много дополнительных параметров. Если будете пользоваться, то почитайте.

Если посмотреть изменения большого репозитория, то в консоли всё это не очень читаемо, так как много информации. Можно немного упростить:

# git log --oneline

Так читается намного лучше.

📌 Теперь краткая инструкция, как перенести репозиторий из одного удалённого сервера в другой.

# git clone --bare git@server01.local:testrepo.git
# cd testrepo.git && git fetch origin
# git remote add new-origin git@server02.local:testrepo.git
# git push --mirror new-origin
# git remote rm origin && git remote rename new-origin origin

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

#git