Kiel Konekti GitLab kaj Pantheon kaj Optimumigi Drupalon kaj WordPress-Laborfluojn

Nia kreinto de gastprogramiloj ĉe Pantheon parolas pri kiel aŭtomatigi WordPress-deplojojn per GitLab CI/CD.

В panteón Mi laboras en rilatoj kun programistoj, do mi ĉiam serĉas novajn manierojn helpi programistojn de WordPress kaj Drupalo solvi problemojn pri aŭtomatigo en siaj laborfluoj. Por fari tion, mi ŝatas eksperimenti kun novaj iloj kaj kombini ilin unu kun la alia por funkcii efike.

Mi ofte vidas programistojn lukti kun ununura sursceniga servilo.

Estas tia plezuro atendi vian vicon por uzi mezan servilon aŭ sendi al klientoj URL kun la noto: "Rigardu ĉi tie, sed ne rigardu ĉi tie ankoraŭ."

Multidev-medioj - unu el la bonegaj Panteonaj iloj - solvas ĉi tiun problemon, ĉar per ili vi povas krei mediojn por Git-filioj laŭpeto. Ĉiu plurdev-medio havas sian propran URL kaj datumbazon, do programistoj povas labori trankvile, kontroli kvaliton kaj akiri aprobon sen surpaŝi unu la alian.

Sed Panteono ne havas ilojn por versio-kontrolo aŭ kontinua integriĝo kaj disvastigo (CI/KD). Sed ĝi estas fleksebla platformo kun kiu vi povas integri ajnajn ilojn.

Mi ankaŭ rimarkis, ke teamoj uzas iujn ilojn por evoluo, kaj malsamajn por kunigo kaj disfaldo.

Ekzemple, ili havas malsamajn ilojn por versio-kontrolo kaj CI/KD. Vi devas ludi kaj ŝanĝi inter iloj por redakti kodon kaj diagnozi problemojn.

En GitLab ekzistas plena aro de evoluiloj: por versio-kontrolo, biletoj, kunfandi petoj, plej bona en-klasa CI/KD-dukto, kontenera registro, kaj ĉio tia. Mi ankoraŭ ne trovis aplikaĵon, kiu proponas tiom multe por administri vian evoluan laborfluon.

Mi amas aŭtomatigon, do mi lernis kiel ligi Panteonon al GitLab, por ke engaĝiĝoj al la ĉefa branĉo de GitLab estu deplojitaj al la ĉefa evolumedio en Pantheon. Kaj kunfandi petojn en GitLab povas krei kaj disfaldi kodon al plurdev-medioj en Panteono.

En ĉi tiu lernilo, mi gvidos vin tra kiel agordi konekton inter GitLab kaj Pantheon kaj optimumigi vian WordPress kaj Drupalo laborfluo.

Kompreneble eblas, spegula GitLab-deponejo, sed ni faros ĉion per niaj manoj por enprofundiĝi GitLab CI kaj estontece uzu ĉi tiun ilon ne nur por deplojo.

Enkonduko

Por ĉi tiu afiŝo, vi devas kompreni, ke Panteono dividas ĉiun retejon en tri elementojn: kodo, datumbazo kaj dosieroj.

La kodo inkluzivas CMS-dosierojn kiel WordPress-kernon, kromaĵojn kaj temojn. Ĉi tiuj dosieroj estas administritaj en Git-deponejoj, gastigita de Pantheon, kio signifas, ke ni povas disfaldi kodon de GitLab al Pantheon kun Git.
Dosieroj en Panteono estas amaskomunikiloj, tio estas bildoj por la retejo. Kutime ili estas alŝutitaj de uzantoj kaj Git ignoras ilin.

Kreu senpagan konton, eksciu pli pri Panteona laborfluo aŭ registriĝu por demo ĉe panteono.io.

Supozoj

Mia projekto pri Pantheon kaj GitLab nomiĝas pantheon-gitlab-blog-demo. La nomo de la projekto devas esti unika. Ĉi tie ni laboros kun WordPress-ejo. Vi povas preni Drupalon, sed vi devos ŝanĝi kelkajn aferojn.

Mi uzos Git komandliniokaj vi povas labori enen grafika interfaco, se vi volas.

Krei projekton

Unue, ni kreu Projekto GitLab (Ni revenos al ĉi tio poste).

Nun kreante WordPress-retejon en Panteono. Poste ni instalas WordPress por la paĝa panelo.

Se viaj manoj jukas por ŝanĝi ion, ekzemple, forigi aŭ aldoni kromaĵojn, paciencu. La retejo ankoraŭ ne estas konektita al GitLab, kaj ni volas, ke ĉiuj kodaj ŝanĝoj trairu GitLab.

Post kiam ni instalas WordPress, reiru al la panelo de la retejo de Pantheon kaj ŝanĝu la disvolvan reĝimon al Git.

Komenca kompromiso sur GitLab

Nun vi devas translokigi la komencan WordPress-kodon de la Pantheon-ejo al GitLab. Por fari tion, ni klonas la kodon el la Git-deponejo de la Pantheon-ejo loke, kaj poste sendas ĝin al la GitLab-deponejo.

Por fari ĝin pli facila kaj sekura, aldonu SSH-ŝlosilon al Panteono kaj ni ne devos enigi pasvorton ĉiufoje kiam ni klonas Pantheon Git-deponejon. Samtempe jam aldonu SSH-ŝlosilon al GitLab.

Por fari tion, klonu la retejon de Pantheon loke kopiante la komandon de la kampo Klonu kun Git sur la paĝa panelo.

Se vi bezonas helpon, legu la dokumentaron komenci kun Git por Pantheon.

Nun ni ŝanĝu git remote originpor montri GitLab anstataŭ Pantheon. Ĝi povas esti farita командой git remote.

Ni iru al la GitLab-projekto kaj kopiu la deponejan URL el la menuo de Klono sur la paĝo de detaloj de la projekto. Ni elektu la opcion Kloni kun SSH, ĉar ni jam agordis la SSH-ŝlosilon.

defaŭlte git remote por loka kopio de la koda deponejo - origin. Ĉi tio povas esti ŝanĝita ĉ git remote set-url origin [URL репозитория GitLab], kie anstataŭ krampoj ni enigas la realan URL.

Fine ni lanĉas git push origin master --forcepor puŝi WordPress-kodon de Pantheon al GitLab.

La opcio –force estas bezonata nur unufoje. Poste en teamoj git push ĝi ne estos sur GitLab.

Agordi akreditaĵojn kaj variablojn

Memoru kiel ni aldonis SSH-ŝlosilon loke por ensaluti al Pantheon kaj GitLab? La SSH-ĵetono povas esti uzata por rajtigi GitLab kaj Pantheon.

GitLab havas bonegan dokumentadon. Ni vidu sekcio pri SSH-ŝlosiloj kiam vi uzas la Docker-ekzekutilon en la dokumento pri uzado de SSH-ŝlosiloj kun GitLab CI/CD.

Ni nun kompletigos la unuajn du paŝojn: Ni kreu novan SSH-ŝlosilparon loke kun ssh-keygen kaj aldonu la privatan ŝlosilon kiel variablon al la projekto.

Tiam ni demandos SSH_PRIVATE_KEY kiom GitLab CI/CD-medivariablo en la projektaj agordoj.
En la tria kaj kvara paŝoj ni kreos dosieron .gitlab-ci.yml kun enhavo tia:

before_script:
  # See https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

Ni ankoraŭ ne transdonu la dosieron .gitlab-ci.yml, tiam vi devos aldoni ion alian al ĝi.

Nun ni plenumas la kvinan paŝon kaj aldonu la publikan ŝlosilon, kiun vi kreis en la unua paŝo al la servoj, al kiuj vi bezonas aliron en la konstrua medio.

En nia kazo, ni volas aliri Pantheon de GitLab. Ni sekvas la instrukciojn en la Panteono-dokumento pri aldonante SSH-ŝlosilon al Pantheon kaj faru ĉi tiun paŝon.

Memoru: privata SSH estas en GitLab, malferma SSH estas en Panteono.

Ni starigu kelkajn pli da mediovariabloj. La unua nomiĝas PANTHEON_SITE. Ĝia valoro estas la nomo de la Panteono-ejo sur via maŝino.

La nomo sur la maŝino estas listigita ĉe la fino de la komando Klono kun Git. Vi jam klonis la retejon loke, do ĉi tio estos la nomo de la loka dosierujo.

Poste, ni starigu la mediovariablon PANTHEON_GIT_URL. Ĉi tiu estas la Git-deponejo URL por la Panteono-ejo, kiun ni jam uzis.

Enigu nur la SSH-deponejon URL, sen git clone kaj la nomo de la retejo sur la maŝino ĉe la fino.

Huf. Tio estas farita, nun ni povas fini nian dosieron .gitlab-ci.yml.

Kreu deplojan taskon

Kion ni komence faros kun GitLab CI estas tre simila al tio, kion ni faris kun Git-deponejoj en la pasinteco. Sed ĉi-foje, ni aldonu la Pantheon-deponejon kiel duan malproksiman Git-fonton, kaj poste ni premu la kodon de GitLab al Pantheon.

Por fari tion, ni agordu scenejo deploy и tasko deploy:dev, ĉar ni deplojos al la evolumedio sur Panteono. La rezulta dosiero .gitlab-ci.yml aspektos tiel:

stages:
- deploy

before_script:
  # See https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

deploy:dev:
  stage: deploy
  environment:
    name: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  only:
    - master

Variabloj SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL devus aspekti konata - ni starigis ĉi tiujn mediovariablojn pli frue. Kun ĉi tiuj variabloj ni povos uzi la valorojn en la dosiero .gitlab-ci.yml multfoje, kaj ili nur bezonos esti ĝisdatigitaj en unu loko.

Fine, aldonu, kompromigu kaj sendu la dosieron .gitlab-ci.yml sur GitLab.

Kontrolante la deplojon

Se ni faris ĉion ĝuste, la tasko deploy:dev funkcios sukcese en GitLab CI/CD kaj sendos kommit .gitlab-ci.yml ĉe Panteono. Ni rigardu.

Sendante kunfadenajn petajn fadenojn al Panteono

Ĉi tie ni uzos mian plej ŝatatan funkcion de Panteono − multdev, kie vi povas krei pliajn Pantheon-mediojn por Git-filioj laŭ postulo.

Aliro al multidev estas limigita, do ĉi tiu sekcio povas esti preterlasita. Sed se vi havas aliron, vi povas serioze pliigi produktivecon agordante aŭtomatan kreadon de multidev-medioj sur Pantheon de GitLab kunfandaj petoj.

Unue ni faru novan Git-branĉon loke uzante git checkout -b multidev-support. Nun ni ŝanĝu ion denove .gitlab-ci.yml.

Mi ŝatas inkluzivi la kunfandan peton-numeron en la Panteona medionomo. Ekzemple, la unua kunfanda peto estas mr-1, dua - mr-2 ktp.

La kunfanda peto ŝanĝiĝas, do ni devas dinamike determini la Panteonajn branĉonomojn. Ĝi estas facila en GitLab - vi nur bezonas uzi antaŭdifinitaj mediovariabloj.

Ni povas preni $CI_MERGE_REQUEST_IIDpor specifi la kunfandigan numeron. Ni apliku ĉion ĉi kune kun la tutmondaj mediaj variabloj, kiujn ni antaŭe specifis kaj aldonu novan taskon deploy:multidev ĉe la fino de la dosiero. .gitlab-ci.yml.

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Checkout the merge request source branch
    - git checkout $CI_COMMIT_REF_NAME
    # Add the Pantheon git repository as an additional remote
    - git remote add pantheon $PANTHEON_GIT_URL
    # Push the merge request source branch to Pantheon
    - git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
  only:
    - merge_requests

Ĝi estos simila al nia tasko deploy:dev, nur la branĉo estas sendita al Panteono, ne al master.

Ni aldonis kaj faris la ĝisdatigitan dosieron .gitlab-ci.yml, kaj nun ni puŝu novan branĉon al GitLab kun git push -u origin multidev-support.

Nun ni kreu novan kunfandan peton de la branĉo multidev-supportper premado Krei kunfandan peton.

Kreinte kunfandan peton, ni rigardas kiel la tasko CI/CD estas efektivigita deploy:multidev.

Rigardu, nova fadeno estis sendita al Panteono. Sed se ni iros al la multidev-sekcio sur la Pantheon-reteja panelo, ni ne vidos la novan medion tie.

Ni rigardu la sekcion Git Branches.

Kiel rezulto, nia fadeno mr-1 alvenis al Panteono. Ni kreu medion el branĉo mr-1.

Ni kreis multidev-medion, nun ni reiru al GitLab kaj rigardu la sekcion Operacioj > Medioj. Ni vidos enskribojn por dev и mr-1.

Ĉi tio estas ĉar ni aldonis enskribon environment Kun nomo name и url en CI/KD-taskojn. Se ni klakas sur la malferma medio-ikono, ni estos kondukitaj al la URL de la multidev-medio sur Panteono.

Aŭtomatigi la kreadon de multidev

Principe, vi povas halti ĉi tie kaj nur memori krei multidev-medion por ĉiu kunfanda peto, sed ĉi tiu procezo povas esti aŭtomatigita.

Panteono havas komandlinian ilon finstacio, kie vi povas labori kun la platformo aŭtomate. Terminus permesas krei multidev-mediojn de la komandlinio - ideala por GitLab CI.

Ni bezonas novan kunfandan peton por testi ĉi tion. Ni kreu novan branĉon uzante git checkout -b auto-multidev-creation.

Por uzi Terminus en GitLab CI/CD-taskoj, vi bezonas maŝinan ĵetonon por aŭtentikigo kun Terminus kaj ujo-bildon kun Terminus.

Kreante Pantheon Machine Token, konservu ĝin en sekura loko kaj aldonu ĝin kiel tutmondan mediovariablon en GitLab kun la nomo PANTHEON_MACHINE_TOKEN.

Se vi forgesis kiel aldoni GitLab-mediajn variablojn, revenu al kie ni difinis PANTHEON_SITE.

Kreante Dockerfile kun Terminus

Se vi ne uzas Docker aŭ ne ŝatas dosierojn Dockerfile, prenu mian bildon registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest kaj preterlasu ĉi tiun sekcion.

GitLab havas konteneran registron, kie ni povas konstrui kaj meti la Dockerfile por nia projekto. Ni kreu Dockerfile kun Terminus por labori kun Pantheon.

Terminus estas PHP-komandlinia ilo, do ni komencu per la PHP-bildo. Mi instalas Terminus per Composer, do mi uzos oficiala bildo de Docker Composer. Ni kreas Dockerfile en la loka dosierujo kun la sekva enhavo:

# Use the official Composer image as a parent image
FROM composer:1.8

# Update/upgrade apk
RUN apk update
RUN apk upgrade

# Make the Terminus directory
RUN mkdir -p /usr/local/share/terminus

# Install Terminus 2.x with Composer
RUN /usr/bin/env COMPOSER_BIN_DIR=/usr/local/bin composer -n --working-dir=/usr/local/share/terminus require pantheon-systems/terminus:"^2"

Sekvu la instrukciojn por kunmeti kaj sendi bildojn de la sekcio Konstruu kaj puŝu bildojn в ujo registra dokumentaropor kolekti bildon de Dockerfile kaj puŝu ĝin al GitLab.

Malfermu la sekcion Registro en la projekto GitLab. Se ĉio iris laŭplane, nia bildo estos tie. Skribu ligon al la bilda etikedo - ni bezonas ĝin por la dosiero .gitlab-ci.yml.

Sekcio script en la problemo deploy:multidev komencas kreski, do ni movu ĝin al aparta dosiero. Kreu novan dosieron private/multidev-deploy.sh:

#!/bin/bash

# Store the mr- environment name
export PANTHEON_ENV=mr-$CI_MERGE_REQUEST_IID

# Authenticate with Terminus
terminus auth:login --machine-token=$PANTHEON_MACHINE_TOKEN

# Checkout the merge request source branch
git checkout $CI_COMMIT_REF_NAME

# Add the Pantheon Git repository as an additional remote
git remote add pantheon $PANTHEON_GIT_URL

# Push the merge request source branch to Pantheon
git push pantheon $CI_COMMIT_REF_NAME:$PANTHEON_ENV --force

# Create a function for determining if a multidev exists
TERMINUS_DOES_MULTIDEV_EXIST()
{
    # Stash a list of Pantheon multidev environments
    PANTHEON_MULTIDEV_LIST="$(terminus multidev:list ${PANTHEON_SITE} --format=list --field=id)"

    while read -r multiDev; do
        if [[ "${multiDev}" == "$1" ]]
        then
            return 0;
        fi
    done <<< "$PANTHEON_MULTIDEV_LIST"

    return 1;
}

# If the mutltidev doesn't exist
if ! TERMINUS_DOES_MULTIDEV_EXIST $PANTHEON_ENV
then
    # Create it with Terminus
    echo "No multidev for $PANTHEON_ENV found, creating one..."
    terminus multidev:create $PANTHEON_SITE.dev $PANTHEON_ENV
else
    echo "The multidev $PANTHEON_ENV already exists, skipping creating it..."
fi

La skripto estas en privata dosierujo kaj ne permesas retan aliron al Panteono. Ni havas skripton por nia multidev-logiko. Ni nun ĝisdatigu la sekcion deploy:multidev dosiero .gitlab-ci.ymltiel ke ĝi rezultu jene:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Ni devas certigi, ke niaj taskoj estas plenumitaj en la kreita propra bildo, do ni aldonu difinon image de registra URL al .gitlab-ci.yml. Kiel rezulto, ni finis kun dosiero tia .gitlab-ci.yml:

image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest

stages:
- deploy

before_script:
  # See https://docs.gitlab.com/ee/ci/ssh_keys/README.html
  - eval $(ssh-agent -s)
  - echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
  - mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "Gitlab CI"

deploy:dev:
  stage: deploy
  environment:
    name: dev
    url: https://dev-$PANTHEON_SITE.pantheonsite.io/
  script:
    - git remote add pantheon $PANTHEON_GIT_URL
    - git push pantheon master --force
  only:
    - master

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Aldoni, fari kaj sendi private/multidev-deploy.sh и .gitlab-ci.yml. Nun ni revenas al GitLab kaj atendas ke la tasko CI/CD finiĝos. Estu pacienca: multidev povas daŭri kelkajn minutojn por krei.

Poste ni rigardu la multidev-liston pri Panteono. Ho miraklo! Multidev-medio mr-2 jam ĉi tie.

konkludo

Mia teamo multe pli amuziĝis kiam ni komencis malfermi kunfandpetojn kaj krei mediojn aŭtomate.

Per la potencaj iloj de GitLab kaj Pantheon, vi povas aŭtomate konekti GitLab al Pantheon.

Ĉar ni uzas GitLab CI/CD, nia laborfluo havos lokon por kreski. Jen kelkaj ideoj por komenci vin:

• Aldonu konstruan paŝon.
• Aldonu aŭtomatan testadon.
• Aldonu taskon por certigi ke kodnormoj estas plenumitaj.
• Aldoni dinamika aplikaĵa sekureca testado.

Sciigu al mi, kion vi pensas pri GitLab, Pantheon kaj aŭtomatigo.

PS Ĉu vi scias, ke Terminus, la komandlinia ilo de Panteono, povas esti etendita per kromaĵoj?

Ni ĉe Panteono faris bonan laboron en la versio 2 de nia kromaĵo por Terminus-konstruaj iloj kun GitLab-subteno. Se vi ne volas ĝeni pri agordoj por ĉiu projekto, provu ĉi tiun kromprogramon kaj helpu nin testi la v2-betaon. Por la Terminus-teamo build:project:create Vi nur bezonas Pantheon-ĵetonon kaj GitLab-ĵetonon. Ŝi deplojos unu el la specimenaj projektoj kun Komponisto kaj aŭtomatigita testado, kreos novan projekton en GitLab, nova Pantheon-ejo, kaj konektos ilin per medio-variabloj kaj SSH-ŝlosiloj.

Pri la aŭtoro

Andrew Taylor kreas ilojn por programistoj en panteón.

fonto: www.habr.com