Automātiska tīmekļa vietnes izmaiņu publicēšana ar Github Actions

Krista Veske21. December, 2023

Šis ieraksts ir novecojis!

Sveiki! Mani sauc Krista, un es esmu Zone front-end programmatūras izstrādātāja. Tāpat kā daudzi citi profesionāli izstrādātāji, arī es dažkārt jūtu, ka ar darbu saistītā koda rakstīšana nav pietiekama, tāpēc ārpus darba rakstu kodu savam pašattīstības nolūkam. Vēlos dalīties savā pieredzē ar noderīgu GitHub funkciju, kas varētu atvieglot tīmekļa vietnes izstrādes procesu.

Savos “pašattīstības ceļojumos” es bieži esmu pieķērusi sevi domājam, cik kaitinoši ir katru reizi pēc nelielām izmaiņām tīmekļa vietnē ieiet servera pārvaldībā, tad failu pārvaldībā, tad atvērt pareizo mapi un aizvietot vecos failus ar jauniem. Būtu daudz vieglāk un ērtāk, ja kāda automatizācija to izdarītu manā vietā. Piemēram, uzreiz pēc izmaiņu nosūtīšanas uz galveno zara versiju vadības sistēmā. Tāpēc nolēmu, ka ir pienācis laiks spert pirmo apzināto soli CI/CD pasaulē un dalīties ar jums savos atklājumos.

Pēc nelielas izpētes es atradu funkcionalitāti ar nosaukumu Actions vietnē GitHub, kuras galvenais mērķis ir automatizēt izstrādātāju darba plūsmu. Actions iespējas ietver koda būvēšanu, testu palaišanu, kā arī koda piegādi no GitHub repozitorija (turpmāk repo) tieši uz serveri.

Vai tas prasa papildu maksu?

Privātiem repo bezmaksas GitHub lietotājiem ir atļautas 2 000 minūtes GitHub Actions darba plūsmas izpildes laika mēnesī.

Publiskiem repo darba plūsmu izpilde vienmēr ir bez maksas, neatkarīgi no minūtēm.

Turklāt jāņem vērā, ka bezmaksas paketē ir līdz 500 MB datu, kas tiek aprēķināti, pamatojoties uz visiem repo, kas pieder jūsu lietotāja kontam.

Ja iepriekš minētie limiti tiek pārsniegti, no šī brīža tiek piemērota maksa saskaņā ar GitHub cenrādi.

Sāksim…

1. Sagatavošanās

Pirmkārt, apskatīsim, kas jums būs nepieciešams:

Zone serveris (der jebkurš mūsu piedāvātais pakotnes veids).
Šajā rakstā kā piemērs izmantots mūsu web hostinga Starter pakotne
GitHub konts
Spēja izmantot komandrindu (SSH atslēgu pāra ģenerēšanai)

Un veiksim dažas sagatavošanās darbības:

1. Sagatavojiet domēnu, kurā nākotnē vēlaties automātiski izvietot savu tīmekļa vietni. Manā piemērā serverim izveidoju apakšdomēnu “actions”

2. Izveidojiet un iestatiet GitHub repo savā tīmekļa vietnes kodā

VAI fork-ojiet kādu no maniem repo testēšanai:

lapa, kurai nav nepieciešama būvēšana (HTML + CSS)
lapa, kurai nepieciešama būvēšana (Vite + Vue)

2. SSH atslēgu pāris un iestatījumi Zone

Ģenerējiet SSH atslēgu pāri. To var izdarīt no komandrindas vai izmantojot tādus rīkus kā PuTTY.

Pieslēdzieties My Zone un atveriet sava servera SSH iestatījumus. Pievienojiet savu publisko atslēgu un atļaujiet piekļuvi no jebkuras vietas, izmantojot Access from nolaižamo izvēlni.*

* Tas varbūt lika jums uzraust uzaci. Noteikti iesaku izlasīt šī bloga raksta pēdējo sadaļu!

3. Slepeno datu pievienošana GitHub repo iestatījumos

Slepenie dati ir repo-specifiski – ja vēlaties iestatīt koda piegādes darba plūsmu uz to pašu serveri no vairākiem dažādiem repo, slepenie dati jāievada katrā repo atsevišķi, ja vien repo nepieder organizācijai.

Atveriet sava repo iestatījumus GitHub un dodieties uz Secrets and variables > Actions sadaļā Security kreisajā izvēlnē.

(Lūdzu, ņemiet vērā! Noklikšķiniet uz attēla, lai to palielinātu.)

Kopumā jāievada trīs slepenie dati:

HOST_SERVER_IP – to var atrast SSH iestatījumu lapā My Zone
SSH_LOGIN_CREDS – nokopējiet sava servera lietotājvārdu un IP adresi no SSH konfigurācijas lapas un atdaliet tos ar @ zīmi (virtXXXX@IPaadress)
SSH_PRIVATE_KEY – iepriekš ģenerētā atslēgu pāra privātā atslēga

Lūdzu, ņemiet vērā! Iesaku nepieciešamo informāciju nokopēt atsevišķā teksta failā, jo, ja pievienojot slepenos datus kaut kur pieļaujat kļūdu, varat mainīt slepenā datu vērtību, bet vecā vērtība netiks parādīta.

Kopēšana atsevišķā teksta failā ir noderīga arī tad, ja vēlaties izveidot koda piegādes darba plūsmu uz to pašu serveri no vairākiem dažādiem repo (piemēram, ja testēšanai fork-ojāt abus iepriekš minētos repo)

4. Workflow faila izveide

Tālāk dodieties uz Actions apakšlapu no repo augšējās izvēlnes un izveidojiet jaunu workflow.

Workflow faila rediģēšanas lapā labajā pusē ir ļoti noderīga sānu josla, kurā var atrast izvilkumu no workflow dokumentācijas un Actions Marketplace.

Esmu sagatavojusi divus workflow failus:

pirmais – tīmekļa lapai, kurai nav nepieciešama būvēšana, t.i., faili vienkārši tiek nokopēti no repo uz serveri
otrais – tīmekļa lapai, kurai pirms failu kopēšanas uz serveri nepieciešama būvēšana. Manā piemērā tā ir Vite + Vue lapa.

Iesaku workflow faila rediģēšanas lapā turēt atvērtu dokumentāciju un Marketplace, lai iepazītos ar failu saturu un izmantotajām Actions.

Pirmais piemērs – deploy

name: Deploy to Zone
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://YOURDOMAIN.EU
    steps:
      - name: Checkout to main
        uses: actions/checkout@main
      - name: Set up SSH
        run: |
          mkdir -p ~/.ssh/
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.HOST_SERVER_IP }} >> ~/.ssh/known_hosts
      - name: Copy files to server
        run: |
          rsync -vrm  ./* ${{ secrets.SSH_LOGIN_CREDS }}:/dataXX/virtXXXXX/domeenid/WWW.YOURDOMAIN.EU/actionsCode language: JavaScript (javascript)

Otrais piemērs – build & deploy

name: Build & Deploy to Zone
on:
  push:
    branches:
      - main
jobs:
  build:
    name: Build
    runs-on: ubuntu-latest

    steps:
      - name: Checkout to main
        uses: actions/checkout@main

      - name: Set up Node
        uses: actions/setup-node@v3.8.1

      - name: Install dependencies
        run:  npm install

      - name: Build project
        run: npm run build

      - name: Upload built files
        uses: actions/upload-artifact@v3.1.3
        with:
          name: production-files
          path: ./dist    
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    needs: build
    
    environment:
      name: production
      url: https://YOURDOMAIN.EU
    
    steps:
    - name: Checkout to main
      uses: actions/checkout@main
    
    - name: Download built files
      uses: actions/download-artifact@v2.1.1
      with:
        name: production-files
        path: ./dist
    
    - name: Connect to server over SSH
      run: |
        mkdir -p ~/.ssh/
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
        chmod 600 ~/.ssh/id_rsa
        ssh-keyscan -H ${{ secrets.HOST_SERVER_IP }} >> ~/.ssh/known_hosts
    
    - name: Deploy built site
      run: |
        rsync -vrm  ./dist/ ${{ secrets.SSH_LOGIN_CREDS }}:/dataXX/virtXXXXX/domeenid/www.YOURDOMAIN.EU/actionsCode language: JavaScript (javascript)

Lūdzu, ņemiet vērā! Abos kodos ir daži atslēgvārdi, kas jāaizvieto ar pareizajām vērtībām:

aizvietojiet “YOURDOMAIN.EU” ar savu domēna vārdu
dataXX ar sava servera nodalījumu (to var atrast My Zone servera pakalpojuma sistēmas datos)
virtXXXXX ar sava servera sistēmas lietotājvārdu
un noteikti pārskatiet galamērķa faila ceļu rsync komandrindā. (Ja vēlaties izvietot tieši galvenajā domēnā un neesat mainījis galvenā domēna saknes direktoriju, nomainiet /actions mapi uz /htdocs rindas beigās)

Iesaku workflow faila rediģēšanas lapā izmantot Marketplace sadaļu, lai pārbaudītu izmantoto Actions versijas un, ja nepieciešams, nomainītu tās uz jaunākām.

Lūdzu, ņemiet vērā! Dotā rsync komanda neizdzēš failus galamērķa direktorijā, bet pārraksta failus ar identisku nosaukumu un paplašinājumu! Ja vēlaties, lai komanda uzvestos citādi, pārbaudiet rsync komandas dokumentāciju.

5. Veiciet commit un vērojiet procesu

Kad workflow fails ir gatavs un pielāgots jūsu vēlmēm, nospiediet commit pogu un vēlreiz atveriet Actions augšā.

Tur vajadzētu redzēt savu pirmo workflow run.

Kādu brīdi, kamēr tas vēl nav izdevies vai nav izgāzies, tam blakus būs oranža ikona. Kad workflow run ir pabeigts, tam vajadzētu izskatīties kā attēlā zemāk.

GitHub Actions gadījumā ir ērti, ka, noklikšķinot uz workflow run apraksta, atveras lapa, kurā var precīzi redzēt, kāda kļūda radās, ja process izgāzās.

Noklikšķinot uz neveiksmīgā darba kreisajā pusē zem Jobs vai galvenajā.yml lodziņā vidū, iespējams redzēt, kurā solī radās kļūda ar detalizētāku kļūdas aprakstu.

Ja workflow bija veiksmīgs, tad, apmeklējot savu vietni, tai vajadzētu būt tādā pašā stāvoklī, kāda tā ir jūsu Github repo galvenajā zarā. Un turpmāk, lai izvietotu, atliek tikai rakstīt kodu un nosūtīt (vai apvienot pull request) uz galveno zaru.

Vai to var padarīt vēl drošāku?

Vai ir iespējams izmantot līdzīgu risinājumu lielāku un kritiski svarīgu tīmekļa vietņu izvietošanai? Tas ir iespējams, taču ar lielāku uzsvaru uz drošību šis process kļūst daudz sarežģītāks. Lielākā problēma manis aprakstītajā risinājumā ir tā, ka viss process sākas ārpus servera, kur katru reizi pieslēdzas serverim caur SSH no citas IP adreses (izmantojam GitHub-hosted runners).

Pat ja privātā SSH atslēga tiek glabāta pēc iespējas drošāk, papildus ieteicams serverī ieviest atļauto IP adrešu sarakstu (allowlist). Diemžēl GitHub to ir padarījis pēc iespējas sarežģītāku parastam lietotājam.

GitHub-hosted runners izmanto Microsoft Azure datu centru IP adrešu diapazonus, kurus var pieprasīt caur API, bet tie tiek mainīti katru nedēļu un vienlaikus var būt simtiem. (Pētot šo bloga rakstu, atklāju, ka GitHub Meta endpoint “actions” atslēgā ir vairāk nekā 3720 IP adrešu diapazonu ar CIDR apzīmējumu, starp kuriem acīmredzot notiek iknedēļas rotācija).

Tehniski mēs varam noņemt IP adreses no allowlist un pievienot tās caur API (nav publiski dokumentēts), bet to darīt ar simtiem IP adrešu diapazonu, visticamāk, jau pārsniedz saprātīgas lietošanas robežas.

Tāpēc arī GitHub savā dokumentācijā norāda, ka neiesaka izmantot GitHub-hosted runners IP adrešu diapazonus allowlist vajadzībām, bet apsvērt alternatīvas. Piemēram, tiek piedāvāti arī lieli runners ar statisku IP adrešu diapazonu, kas ir maksas un pieejami tikai organizācijām vai GitHub Team / Enterprise Cloud lietotājiem. Ir iespējams izmantot arī self-hosted runners, par kuriem GitHub nepiemēro papildu maksu.

(src: https://docs.GitHub.com/en/actions/using-GitHub-hosted-runners/about-GitHub-hosted-runners/about-GitHub-hosted-runners#ip-addresses)

Tomēr, visticamāk, vēl labāk ir izdomāt risinājumu, kur viss process notiek iekšēji uz servera, piemēram, izmantojot Jenkins.