Как развернуть Git на хостинге / СоХабр

Что ещё почитать?

git-ssb-intro: a guide to hacking together on the distributed web

Другие способы децентрализации git:

.babelrc

{ "presets": [ [ "@babel/preset-env", { "targets": { "browsers": [">0.25%", "not ie 11", "not op_mini all"] } } ], "@babel/preset-react" ], "plugins": [ "babel-plugin-styled-components", "@babel/plugin-transform-runtime" ]
}

Настройки для создания нашего react_bundle с поддержкой браузеров используемых более >0.25% пользователей.

.gitignore

Тут мы указываем те файлы/папки, которые мы не хотим выгружать на github. Они будут только на данном устройстве и git не будет отслеживать/показывать их изменения. Открываем и вставляем:

/node_modules/
/logs/*
# exception to the rule
!logs/.gitkeep
/public/react_bundle.js
/public/isProd.js

Так как github не выгружает пустые папки, то можно внутрь что-нибудь положить, к примеру пустой файл .gitkeep. Сохраняем файл и закрываем.

Client.js

import React from 'react'
import { render } from 'react-dom'
render(<div>Реакт!!</div>, document.getElementById('cookies'))

Рендерит наш фронтэнд в div с тегом cookies.

pm2-watch.json — позволяет на хостинге командой «npm run server» запустить сервер с отслеживанием изменений в коде и автоматической перезагрузкой.

Compute cloud

Тут у нас будут происходить вычисления 🙂 То есть мы создадим виртуальную машину с Linux (я выбрал ubuntu 18.04), установим node.js приложения и postgreSQL.

Жмём создать ВМ, выкручиваем все настройки на минимум, так как при разработке нагрузки не будет (когда наше приложение выйдет в свет, тогда и подкрутим побольше, ну и будем мониторить по графикам).

Git hosting | 20x faster git web hosting

Github

Github — это место, где будет лежать код нашего приложения. Если коротко, принцип работы для одного человека следующий:

Всё быстро, просто и удобно.

Собственно регистрируемся на Github и создаём private репозиторий для нашего приложения (он будет доступен только нам):

Git-хостинг — удобный, простой, тупой — есть ли?

Pricing · plans for every developer

Public

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

Отдельно остановимся на двух файлах:

index.html:

Visual studio code

Для начала выберем редактор исходного кода, где будем работать. Я выбрал Visual studio code, так он прост, удобен, в нём много плагинов и можно настроить синхронизацию настроек если вы работаете с нескольких устройств. Собственно скачиваем, устанавливаем, запускаем, выбираем общую папку приложений, так как git clone создаст нам свою.

Плагины я использую следующие:

Устанавливаем git для ПК.Открываем консоль в VScode с помощью ctrl shift ` или terminal>new terminal

Отступление:

В консоли windows плохо с русскими символами и чтобы не было крякозяблов нужно открыть file>preferences>settings, ввести в поле terminal.integrated.shellArgs.windows, нажать

И добавить строку «terminal.integrated.shellArgs.windows»: [«-NoExit», «/c», «chcp 65001»],

Повторяем команду для загрузки файлов с github:

Webpack.config.js

Сборщик реакт приложения:

const webpack = require('webpack'), path = require('path'), BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
module.exports = (env, argv) => { let prod = argv.mode == 'production' let config = { entry: './client.js', output: { path: path.resolve('./public'), filename: 'react_bundle.js' }, module: { rules: [ { test: /.(js|jsx)$/, exclude: /node_modules/, loader: 'babel-loader' }, { test: /.css$/, use: ['style-loader', 'css-loader'] } ] }, resolve: { alias: { client: path.resolve('./client/shared'), public: path.resolve('./public') } }, plugins: [ argv.analyze ? new BundleAnalyzerPlugin() : false, prod ? new webpack.optimize.AggressiveMergingPlugin() : false, new webpack.ContextReplacementPlugin(/moment[/\]locale$/, /ru/) ].filter(Boolean), optimization: { minimize: prod ? true : false }, performance: { hints: false } } return config
}

Если коротко, то он открывает файл client.js и все что у него внутри, собирая react_bundle и помещая его в папку public, откуда потом через открытый index.html он будет загружен.

Автоматически обновляемый ssl

Когда вы купите себе домен и привяжете его к IP облака, пример

Выбор хостинга

На своё хобби я готов был тратить 10$ в месяц, поэтому выбирал тот хостинг, с которым планировал и остаться в будущем. Как я и говорил, до этого у меня был 0 опыт, в том числе и с хостингом сайтов. Я попробовал и отказался от следующих:

Jelastic: красивый и удобный интерфейс, вроде всё интуитивно, масштабируемо и понятно. Тем не менее столкнулся с трудностями при настройке (nginx почему-то из vps не хотел работать, только их отдельным модулем) и подключении SSL(и автоматическом обновлении) к русскоязычном домену стандартными средствами (обещали баг пофиксить, но я не хочу ждать)

Делаем всё удобно или цикл разработки с помощью git

Всё вроде работает, но мы же не будем работать всё время подключаясь к облаку. К тому же вдруг мы будем в будущем работать не одни.

Запустить web-интерфейс

$ git-ssb-web

Перейдя по напечатанной в консоли ссылке вы увидите хронологический список коммитов, issue и других действий в видимых репозиториях. Это, разумеется, не всё, а только то, что скачалось после подписки на предыдущем шаге. Нажав на имя пользователя вы увидите его activity log, нажав на репозиторий — интерфейс, похожий на GitHub.

Запушить существующий репозиторий

Вы добавили ssb ссылку в качестве дополнительного remote к вашему репозиторию. Теперь можно пушить.

Важно: невозможно удалить что-то из SSB. Не ставьте эксперименты на чувствительных данных.

$ git push ssb master

Если репозиторий большой, то может не получиться. В git-ssb допустимый размер pack-файла зависит от максимального размера blob, а он ограничен 5Mb. Больший размер сеть не примет. Но закоммитить, тем не менее, возможно:

$ git push ssb master -o allow-big

Клонировать репозиторий

Будем ставить эксперименты с git-ssb на репозитории git-ssb. В SSB нет DNS и красивых названий чего бы то ни было. Ссылку на репозиторий ssb://%n92DiQh7ietE R X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 я скопировал из web-интерфейса.

$ git clone ssb://%n92DiQh7ietE R X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 git-ssb
$ cd git-ssb
$ git remote -v
origin ssb://%n92DiQh7ietE R X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (fetch)
origin ssb://%n92DiQh7ietE R X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (push)

В этом репозитории у нас единственный remote, и он из SSB.

Настройка bitvise ssh

Папка server

Тут лежит на бэкэнд и все пути.

logger.js — в зависимости от среды isProd логирует или в консоль или в errors.log

'use strict'
const pino = require('pino'), isProd = require('../public/isProd')
let logOptions = isProd ? { level: 'warn', // уровень логирования timestamp: () => { return ',"time":"' new Date() '"' } } : { level: 'warn', prettifier: require('pino-pretty'), prettyPrint: { levelFirst: true, translateTime: true } }
let dest = isProd ? pino.destination('./logs/errors.log') : pino.destination(1)
let log = pino(logOptions, dest)
module.exports = log

server/api/

open.js — сюда добавляем наши пути.

'use strict'
module.exports = function(fastify, options, next) { fastify.route({ method: 'GET', url: '/', handler: async (req, res) => { res.send('api / route') } }) fastify.route({ method: 'GET', url: '/hi', handler: async (req, res) => { res.send('api / route hi') } }) next()
}

После настройки и проверки всего на Localhost, просто выгружаем всё на github, а оттуда git pull на хостинг. Всё что на хостинге нужно будет сделать, это установить модули node.js командой «npm i» и создать файл isProd.js

Подключаемся к облаку с пк и выбираем бесплатный ssh клиент

Стандартный Putty позволяет работать только командной строкой, а так как мне пользователю windows это непривычно, то я начал искать клиент с псевдо-проводником. Сначала я попробовал Mobaxterm, но он после какого-то времени простоя отключается, проводник вообще зависает, поэтому сейчас работаю с

и пока проблем как у Mobaxterm не наблюдаю.

Получите инвайт и примите его

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

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

$ ssb-server invite.accept <ваш-инвайт-код>

Теперь вы с тем узлом взаимные друзья: вы начинаете копировать себе данные его и его друзей, а он — ваши.

Предисловие

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

Не буду рассказывать как я изучал javascript, node.js, react, html, css и т.п., перейдём к тому, к чему я пришел на данный момент, чем хотел бы с вами поделится и, конечно, послушать конструктивную критику специалистов.

Как и многие я тренировался на собственном ПК на localhost:3000, создавал front/back-end’ы, верстал, работал с api и т.д., но меня всегда тревожила мысль а том, как же всё это потом перенести на хостинг? Будет ли оно работать? Нужно ли будет переписывать из-за этого код?

Пушить в чужой репозиторий

Это не баг, а фича. Согласно документации (git-ssb-intro), это одна из принятых моделей совместной работы. Вы создаёте в чужом репозитории ветку с именем @ваш-юзернейм/master (git checkout -b @ваш-юзернейм/master), пушите в неё (git push ssb), а после делаете пулл-реквест (git ssb pull-request). Но ничто не помешает вам запушить прямо в master без всяких пулл-реквестов.

Возможность асинхронного внесения изменений в одну ветку может привести к конфликту, если при помощи двух разных identity (про identity — см. ниже) были созданы два конкурирующих коммита. Когда git-ssb встречает такие ситуации, он просит пользователя сделать слияние этих альтернативных версий.

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

Identity задаётся закрытым ключом в файле ~/.$ssb_appname/secret. Если переменная ssb_appname не задана, то будет использована identity по умолчанию (~/.ssb). Если в указанном месте нет файла secret, то ssb-server его создаст со случайным ключом.

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

С другой стороны, это может привести к распространению вредоносного кода: вы делаете что-то полезное, все об этом знают, клонируют и делают sudo make install не глядя в историю коммитов. У одних пользователей установится ваше приложение, а у других — ваше приложение с добавлением зловреда.

Обсуждение этой возможности внутри SSB.

Сделать пулл-реквест

Вы внесли изменения и сделали коммит.

$ git-ssb pull-request

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

Создать репозиторий

$ mkdir my-new-repo
$ cd my-new-repo
$ git init
Initialized empty Git repository in /tmp/my-new-repo/.git/
$ git-ssb create ssb my-new-repo
Created repo: ssb://<hash-code>.sha256 (my-new-repo)
Added remote: ssb
$ git remote -v
ssb ssb://<hash-code>.sha256 (fetch)
ssb ssb://<hash-code>.sha256 (push)

К привычному git init добавилась команда git-ssb create ssb my-new-repo, которая запишет в вашу историю факт создания нового репозитория с именем my-new-repo и добавит его URL в качестве remote с именем ssb. Аналогичным образом можно добавить такой remote к любому существующему репозиторию.

Успех!

Это все, после этого можно клонировать репозиторий и работать:

Установите ssb-server и git-ssb

ssb-server нужен для синхронизации с другими узлами в p2p сети. Он должен быть запущен, когда вы делаете push, pull, fetch, создаёте pull-request или форкаете репозиторий.

Пакет git-ssb включает:

Все три компонента взаимодействуют с запущенным на вашей машине ssb-server.

$ sudo apt install git nodejs npm
$ npm install ssb-server git-ssb

ssb-server и git-ssb установятся в папку $HOME/node_modules. Чтобы было удобнее их вызывать, добавьте в конец файла ~/.profile стоки:

if [ -d "$HOME/node_modules/.bin/" ] ; then PATH="$HOME/node_modules/.bin/:$PATH"
fi

Чтобы переменная $PATH обновилась в текущей сессии, наберите

$ source ~/.profile

Форкнуть репозиторий

$ git-ssb fork my-fork
Created repo: ssb://<new-hash-code>.sha256 (git-ssb)
Added remote: my-fork
$ git remote -v
my-fork ssb://<new-hash-code>.sha256 (fetch)
my-fork ssb://<new-hash-code>.sha256 (push)
origin ssb://%n92DiQh7ietE R X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (fetch)
origin ssb://%n92DiQh7ietE R X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (push)

В вашей истории появится запись о создании нового репозитория, а в текущей папке добавится новый remote.

Шаг 3

В папке public_html инициализируем новый репозиторий и добавим файлы под контроль версий.

cd ~/public_html

git init

git add -A

git commit -m 'Init'

Шаг 1

Создаем FTP-юзера с доступом к корневой директории сайта (на уровень ниже от public_html) и включаем для него SSH. Сразу же запишем куда-нибудь доступы. Мы храним их в таком формате:

Шаг 2

В корневой сайте создаем папку. ssh, а в ней файл authorized_keys. Туда запишем ssh-ключи людей, которые будут работать с этим проектом. Можно это сделать через ФТП, но мне привычней через SSH.

Шаг 4

Создаем новый репозиторий, который будет служить шлюзом для основного

cd ../

git clone --bare public_html project.git

cd public_html

git remote add hub ../project.git

git remote show hub

Последняя команда не обязательна. Она нужна, чтобы удостоверится, что все ок.

Шаг 5

В /public_html/.git/hooks/ создаем файл post-commit и ставим ему права 700.

cd ~/public_html/.git/hooks

touch post-commit

chmod 700 post-commit

nano post-commit

Внутрь помещаем следующее:

Шаг 6

В /project.git/hooks/ создаем файл post-update и ставим ему права 700.

cd ~/project.git/hooks

touch post-update

chmod 700 post-update

nano post-update

Внутрь помещаем следующее: