Comments 15
Все же скрины важнее и должны быть больше разрешением, а не на половину, потому что обязательно этот водяной знак на пол картинки
Жалко что не написали как gitops делается на vps. По факту это настолько просто что целый специальный хостинг без надобности. Достаточно вместо того чтобы делать docker compose up напрямую на сервере создать удалённый контекст:
docker context create vps --docker "host=ssh://me@example.com"
docker context use vps
И можно деплоить на vps из того же github workflow.
Славная статья! Для новичков, самое то!
Спасибо. ) Очень полезный пошаговый гайд с отличной визуализацией каждого шага.
NFS? Коли не ошибаюсь для докер компоуз можно из коробки пользоваться, а для сварма плагин какой-то нужен.
И запуск контейнеров от пользователя, как-то мало об этом.
Хотя и кажется мне что это для следующей статьи))) Спасибо годная статья) Моё почтение и уважение.
Не совсем понял про NFS (знаю только файловую систему такую), нужно уточнение.
Про запуск контейнеров от пользователя, в смысле без композа? Я честно не вижу в этом большого смысла. Если запускать один контейнер локально, ещё ладно, но на серваке гораздо удобнее пользоваться композом. Моё мнение.
Однако, идеи для следующих статей принимаю)
Хм... Как бы сказать. NFS... Расширение памяти(HDD;SSD) для хостов за счёт других хостов. В контексте docker-compose, NFS оглашается в volume (нужен настроенный серверNFS) . В сварм из коробки точно не работает, можно использовать bind на каталог NFS тогда содержание доступно на других холстах: так работает.
Теперь о user в докер компоуз оглашается user "1000":"1000" ("uid":"gid") либо user : container_user. Чтобы контейнер работал не от рута и при использовании бинд не было проблем с доступом к данным. В контейнере там ид юзера и ид группы 1000 и 1000 и на хосту по умолчанию те самые айдишники... В сценарии использования кластера сварм - унификация пользователей, этот вопрос доступа стоит остро. Наверно половина образов которые запускал, работали от рута. В своё время намучался с этим...
Установка Git
Обычно во всех операционках бывает два метода установки: через мастер установки, либо через менеджер пакетов. И Windows тут не исключение:
winget install --id Git.Git -e --source winget
winget install --id Microsoft.GitCredentialManager -e --source winget
winget install --id GitHub.GitLFS -e --source winget
git config --global credential.helper manager
git config --global pull.rebase falseНа macOS тоже есть графический установщик, но сопровождающие проекта его забросили и не делают свежих версий, поэтому остались только менеджеры пакетов. Ваша команда не полная и лучше ставить полный пакет:
brew install git git-lfs git-credential-manager git-gui
git config --global credential.helper managerТут есть небольшой парадокс. Мы ставим Git через Homebrew, который не является штатной программой macOS, и чтобы установить сам Homebrew уже нужен Git. Такая вот рекурсия. Но не переживайте — для самой установки Homebrew достаточно минимальной встроенной версии Git, которая входит в состав Xcode Command Line Tools. Если Git ещё не установлен, macOS сама предложит установить эти инструменты при первой попытке вызвать git в терминале. На самом деле, скрипт установки Homebrew делает это автоматически, так что всё произойдёт без вашего вмешательства. Эта версия подходит для скачивания Homebrew, но она обычно устаревшая и не поддерживает современные возможности Git, которые вам точно пригодятся в работе.
Во всевозможных линуксах ставим эти же пакеты через их пакетные менеджеры.
git config --global user.name "Ваше Имя"
git config --global user.email "you@example.com"Первая команда задаёт ваше имя, которое будет отображаться в коммитах, а вторая — ваш адрес электронной почты. Эти данные необходимы, чтобы git мог корректно отправлять изменения в удалённый репозиторий (например, на git-хостинги). Без них управление версиями не будет работать должным образом, и вы не сможете синхронизировать свои изменения с удалённой версией проекта.
Не первый раз встречаю подобные странные утверждения в статьях про Git. Откуда вы это вообще берете? Приведите первоисточник или место в документации.
Имя и email это просто строчки, которыми подпишутся ваши коммиты и никакой другой функции они не несут. Вы можете подписываться хоть Вася Пупкин elon@x.com. Каким образом подписи коммитов могут помешать отправить их в вышестоящие репозитории? Аутентификация никак не зависит от содержимого коммитов, от слова совсем.
Следующей командой мы подключим удалённый репозиторий:
git remote add origin https://github.com/proDreams/tempProject.gitНа самом деле эта команда ничего не подключает. Тут всего лишь создаётся служебная переменная с именем origin и в неё сохраняется адрес одного из вышестоящих репозиториев. Это имя в дальнейшем мы сможем использовать как короткий псевдоним при отправке и получении коммитов. Но ничего не мешает нам отправить и так:
git push https://github.com/proDreams/tempProject.git mainСвязи в гите создаются не между репозиториями, а между конкретными парами веток разных репозиториев. Ключик --set-upstream как раз и создаёт эту связь между парой веток. Причем ветки могут даже иметь разные названия.
При первом запросе вас попросят ввести логин и пароль от удалённого репозитория.
Это попросят только у тех, кто поленился установить git-credential-manager
У всех остальных выскакивает красивое окно, позволяющее буквально в один клик дать гиту доступ к вашему GitHub или другому хостингу.
Но если вы не подключили менеджер, тогда:
При первом запросе вас попросят ввести логин и пароль от удалённого репозитория. Вместо пароля можно ввести Personal Access Token (PAT), который предоставляет доступ к вашему репозиторию без необходимости вводить пароль.
Не можно, а нужно — пароль в терминале у вас просто не примет. Так как GitHub прекратил поддержку аутентификации по паролю в августе 2021 года , Bitbucket Cloud (bitbucket.org) также прекратил поддержку аутентификации по паролю для API и базовой аутентификации по https в марте 2022 года.
Спасибо!
Шпаргалка для новичков — от GIT до Деплоя