Proposo llegir la transcripció de l'informe d'Alexander Sigachev d'Inventos "Procés de desenvolupament i prova amb Docker + Gitlab CI"
Aquells que tot just comencen a implementar el procés de desenvolupament i prova basat en Docker + Gitlab CI solen fer preguntes bàsiques. Per on començar? Com organitzar-se? Com provar?
Aquest informe és bo perquè parla de manera estructurada sobre el procés de desenvolupament i prova amb Docker i Gitlab CI. L'informe en si és del 2017. Crec que d'aquest informe es poden aprendre els fonaments, la metodologia, la idea, l'experiència d'ús.
A qui li importa, si us plau, sota el gat.
Em dic Alexander Sigachev. Treballo per Inventos. Us explicaré la meva experiència amb l'ús de Docker i com l'estem implementant a poc a poc en els projectes de l'empresa.
Tema de presentació: Procés de desenvolupament amb Docker i Gitlab CI.
Aquesta és la meva segona xerrada sobre Docker. En el moment del primer informe, només fèiem servir Docker en desenvolupament en màquines de desenvolupament. El nombre d'empleats que van utilitzar Docker era d'unes 2-3 persones. A poc a poc es va anar agafant experiència i vam anar una mica més enllà. Enllaç al nostre .
Què hi haurà en aquest informe? Compartirem la nostra experiència sobre quin rasclet hem recollit, quins problemes hem resolt. No a tot arreu era bonic, però permetia seguir endavant.
El nostre lema és: acoblar tot el que podem tenir a les nostres mans.
Quins problemes estem resolent?
Quan hi ha diversos equips en una empresa, el programador és un recurs compartit. Hi ha etapes en què un programador es treu d'un projecte i es lliura durant algun temps a un altre projecte.
Perquè el programador entengui ràpidament, ha de descarregar el codi font del projecte i posar en marxa l'entorn tan aviat com sigui possible, cosa que li permetrà avançar resolent els problemes d'aquest projecte.
Normalment, si comenceu des de zero, hi ha poca documentació al projecte. La informació sobre com configurar-la només està disponible per als antics. Els empleats configuren el seu lloc de treball pel seu compte en un o dos dies. Per accelerar-ho, hem utilitzat Docker.
El següent motiu és l'estandardització de la configuració al desenvolupament. Segons la meva experiència, els desenvolupadors sempre prenen la iniciativa. En cada cinquè cas, s'introdueix un domini personalitzat, per exemple, vasya.dev. Assegut al seu costat hi ha el seu veí Petya, el domini del qual és petya.dev. Desenvolupen un lloc web o algun component del sistema amb aquest nom de domini.
Quan el sistema creix i aquests noms de domini comencen a configurar-se, sorgeix un conflicte de l'entorn de desenvolupament i la ruta del lloc es reescriu.
El mateix passa amb la configuració de la base de dades. Algú no es preocupa amb la seguretat i treballa amb una contrasenya d'arrel buida. En l'etapa d'instal·lació, MySQL va demanar una contrasenya a algú i la contrasenya va resultar ser 123. Sovint passa que la configuració de la base de dades canvia constantment depenent del compromís del desenvolupador. Algú ha corregit, algú no ha corregit la configuració. Hi va haver trucs quan vam treure algun tipus de configuració de prova .gitignore i cada desenvolupador havia d'instal·lar la base de dades. Això va fer difícil començar. Cal, entre altres coses, recordar sobre la base de dades. Cal inicialitzar la base de dades, introduir una contrasenya, registrar un usuari, crear una taula, etc.
Un altre problema són les diferents versions de les biblioteques. Sovint passa que un desenvolupador treballa amb diferents projectes. Hi ha un projecte Legacy que va començar fa cinc anys (a partir del 2017 - nota ed.). En el moment del llançament, vam començar amb MySQL 5.5. També hi ha projectes moderns on intentem implementar versions més modernes de MySQL, per exemple, 5.7 o anteriors (el 2017 - nota de l'ed.)
Qualsevol persona que treballi amb MySQL sap que aquestes biblioteques porten dependències. És bastant problemàtic executar 2 bases juntes. Almenys, els clients antics tenen problemes per connectar-se a la nova base de dades. Això al seu torn crea diversos problemes.
El següent problema és quan un desenvolupador treballa en una màquina local, utilitza recursos locals, fitxers locals, RAM local. Tota la interacció en el moment de desenvolupar una solució als problemes es duu a terme en el marc del fet que funciona en una màquina. Un exemple és quan tenim servidors backend a Production 3 i el desenvolupador desa fitxers al directori arrel i des d'allà nginx agafa fitxers per respondre a la sol·licitud. Quan aquest codi entra a la producció, resulta que el fitxer està present en un dels 3 servidors.
La direcció dels microserveis s'està desenvolupant ara. Quan dividim les nostres grans aplicacions en alguns components petits que interactuen entre ells. Això us permet seleccionar tecnologies per a una pila específica de tasques. També us permet compartir el treball i les responsabilitats entre desenvolupadors.
El desenvolupador Frondend, que es desenvolupa a JS, gairebé no té cap influència en el Backend. El desenvolupador backend, al seu torn, desenvolupa, en el nostre cas, Ruby on Rails i no interfereix amb Frondend. La interacció es realitza mitjançant l'API.
Com a avantatge, amb l'ajuda de Docker, vam poder reciclar recursos a Staging. Cada projecte, per les seves especificitats, requeria una configuració determinada. Físicament, calia assignar un servidor virtual i configurar-los per separat, o compartir algun tipus d'entorn variable i els projectes podien, segons la versió de les biblioteques, influir-se mútuament.
Eines. Què fem servir?
- Docker mateix. El Dockerfile descriu les dependències d'una única aplicació.
- Docker-compose és un paquet que reuneix algunes de les nostres aplicacions Docker.
- Utilitzem GitLab per emmagatzemar el codi font.
- Utilitzem GitLab-CI per a la integració del sistema.
L'informe consta de dues parts.
La primera part parlarà de com es va executar Docker a les màquines dels desenvolupadors.
La segona part parlarà de com interactuar amb GitLab, com fem proves i com ens despleguem a Staging.
Docker és una tecnologia que permet (utilitzant un enfocament declaratiu) descriure els components necessaris. Aquest és un exemple de Dockerfile. Aquí declarem que estem heretant de la imatge oficial de Ruby:2.3.0 Docker. Conté la versió 2.3 de Ruby instal·lada. Instal·lem les biblioteques de compilació necessàries i NodeJS. Descrivim que creem un directori /app. Estableix el directori de l'aplicació com a directori de treball. En aquest directori col·loquem el Gemfile i el Gemfile.lock mínims necessaris. A continuació, construïm els projectes que instal·len aquesta imatge de dependència. Indiquem que el contenidor estarà preparat per escoltar al port extern 3000. L'última ordre és l'ordre que llança directament la nostra aplicació. Si executem l'ordre d'inici del projecte, l'aplicació intentarà executar i executar l'ordre especificada.
Aquest és un exemple mínim d'un fitxer docker-compose. En aquest cas, mostrem que hi ha una connexió entre dos contenidors. Això es troba directament al servei de base de dades i al servei web. Les nostres aplicacions web en la majoria dels casos requereixen algun tipus de base de dades com a backend per emmagatzemar dades. Com que estem utilitzant MySQL, l'exemple és amb MySQL, però res no ens impedeix utilitzar alguna altra base de dades (PostgreSQL, Redis).
Agafem de la font oficial del hub Docker la imatge de MySQL 5.7.14 sense canvis. Recollim la imatge responsable de la nostra aplicació web del directori actual. Ens recull una imatge durant el primer llançament. A continuació, executa l'ordre que estem executant aquí. Si tornem enrere, veurem que s'ha definit l'ordre de llançament via Puma. Puma és un servei escrit en Ruby. En el segon cas, anul·lem. Aquesta ordre pot ser arbitrària segons les nostres necessitats o tasques.
També descrivim que hem de reenviar un port a la nostra màquina amfitrió del desenvolupador del 3000 al 3000 al port del contenidor. Això es fa automàticament mitjançant iptables i el seu mecanisme, que està directament incrustat a Docker.
El desenvolupador també pot, com abans, accedir a qualsevol adreça IP disponible, per exemple, 127.0.0.1 és l'adreça IP local o externa de la màquina.
L'última línia diu que el contenidor web depèn del contenidor db. Quan cridem a l'inici del contenidor web, docker-compose primer ens iniciarà la base de dades. Ja a l'inici de la base de dades (de fet, després del llançament del contenidor! Això no garanteix la preparació de la base de dades) llançarà l'aplicació, el nostre backend.
Això evita errors quan la base de dades no s'obre i estalvia recursos quan aturem el contenidor de la base de dades, alliberant així recursos per a altres projectes.
Què ens dóna l'ús de l'acoblament de bases de dades al projecte. Arreglem la versió de MySQL per a tots els desenvolupadors. Això evita alguns errors que es poden produir quan les versions divergeixen, quan canvien la sintaxi, la configuració i els paràmetres per defecte. Això us permet especificar un nom d'amfitrió comú per a la base de dades, l'inici de sessió i la contrasenya. Ens estem allunyant del zoològic de noms i conflictes en els fitxers de configuració que teníem abans.
Tenim l'oportunitat d'utilitzar una configuració més òptima per a l'entorn de desenvolupament, que serà diferent de la predeterminada. MySQL està configurat per a màquines febles de manera predeterminada i el seu rendiment fora de la caixa és molt pobre.
Docker us permet utilitzar l'intèrpret Python, Ruby, NodeJS, PHP de la versió desitjada. Ens desfer-nos de la necessitat d'utilitzar algun tipus de gestor de versions. Anteriorment, Ruby utilitzava un paquet rpm que us permetia canviar la versió en funció del projecte. També permet, gràcies al contenidor Docker, migrar sense problemes el codi i versionar-lo juntament amb dependències. No tenim cap problema per entendre la versió tant de l'intèrpret com del codi. Per actualitzar la versió, baixeu el contenidor antic i aixequeu el contenidor nou. Si alguna cosa va fallar, podem baixar el contenidor nou, aixecar el contenidor antic.
Després de construir la imatge, els contenidors tant en Desenvolupament com en Producció seran els mateixos. Això és especialment cert per a instal·lacions grans.
A Frontend fem servir JavaScipt i NodeJS.
Ara tenim l'últim projecte a ReacJS. El desenvolupador va executar tot el contenidor i es va desenvolupar mitjançant la recàrrega en calent.
A continuació, s'inicia la tasca de muntatge de JavaScipt i el codi compilat en estàtica es dóna mitjançant recursos d'estalvi de nginx.
Aquí us he donat l'esquema del nostre darrer projecte.
Quines tasques es van resoldre? Teníem la necessitat de construir un sistema amb el qual els dispositius mòbils interactuessin. Reben dades. Una possibilitat és enviar notificacions push a aquest dispositiu.
Què hem fet per això?
Hem dividit en l'aplicació components com ara: la part d'administració a JS, el backend, que funciona a través de la interfície REST a Ruby on Rails. El backend interactua amb la base de dades. El resultat que es genera es lliura al client. El tauler d'administració interactua amb el backend i la base de dades mitjançant la interfície REST.
També hem tingut la necessitat d'enviar notificacions push. Abans teníem un projecte que implementava un mecanisme que s'encarrega de lliurar notificacions a les plataformes mòbils.
Hem desenvolupat el següent esquema: un operador del navegador interactua amb el panell d'administració, el panell d'administració interactua amb el backend, la tasca és enviar notificacions push.
Les notificacions push interactuen amb un altre component que s'implementa a NodeJS.
Es creen cues i després s'envien notificacions segons el seu mecanisme.
Aquí es dibuixen dues bases de dades. De moment, amb l'ajuda de Docker, fem servir 2 bases de dades independents que no estan relacionades de cap manera. A més, tenen una xarxa virtual comuna i les dades físiques s'emmagatzemen en diferents directoris de la màquina del desenvolupador.
El mateix però en xifres. Aquí és on la reutilització del codi és important.
Si abans parlàvem de la reutilització de codi en forma de biblioteques, en aquest exemple, el nostre servei que respon a les notificacions Push es reutilitza com a servidor complet. Proporciona una API. I el nostre nou desenvolupament ja hi interactua.
En aquell moment, estàvem utilitzant la versió 4 de NodeJS. Ara (el 2017 - nota de l'ed.) en desenvolupaments recents fem servir la versió 7 de NodeJS. No hi ha cap problema en components nous per implicar noves versions de biblioteques.
Si cal, podeu refactoritzar i augmentar la versió de NodeJS des del servei de notificació Push.
I si podem mantenir la compatibilitat de l'API, llavors serà possible substituir-la per altres projectes que s'utilitzaven anteriorment.
Què necessites per afegir Docker? Afegim un Dockerfile al nostre repositori, que descriu les dependències necessàries. En aquest exemple, els components es desglossen lògicament. Aquest és el conjunt mínim d'un desenvolupador backend.
En crear un nou projecte, creem un Dockerfile, descriurem l'ecosistema desitjat (Python, Ruby, NodeJS). A docker-compose, descriu la dependència necessària: la base de dades. Descrivim que necessitem una base de dades de tal o tal versió, emmagatzemar dades allà i allà.
Utilitzem un tercer contenidor separat amb nginx per servir estàtica. És possible pujar imatges. El backend els posa en un volum prèviament preparat, que també es munta en un contenidor amb nginx, que dóna l'estàtica.
Per emmagatzemar la configuració nginx, mysql, hem afegit una carpeta Docker on emmagatzemem les configuracions necessàries. Quan un desenvolupador fa un clon git d'un dipòsit a la seva màquina, ja té un projecte preparat per al desenvolupament local. No hi ha dubte sobre quin port ni quina configuració s'ha d'aplicar.
A continuació, tenim diversos components: admin, inform-API, notificacions push.
Per tal de començar tot això, vam crear un altre dipòsit, que vam anomenar dockerized-app. De moment utilitzem diversos repositoris abans de cada component. Són només lògicament diferents: a GitLab sembla una carpeta, però a la màquina del desenvolupador, una carpeta per a un projecte específic. Un nivell més avall són els components que es combinaran.
Aquest és un exemple només del contingut de l'aplicació dockerized. També portem aquí el directori Docker, on omplim les configuracions necessàries per a les interaccions de tots els components. Hi ha un README.md que descriu breument com executar el projecte.
Aquí hem aplicat dos fitxers docker-compose. Això es fa per poder córrer per passos. Quan un desenvolupador treballa amb el nucli, no necessita notificacions push, simplement llança un fitxer docker-compose i, en conseqüència, es desa el recurs.
Si cal integrar-se amb les notificacions push, es llançaran docker-compose.yaml i docker-compose-push.yaml.
Com que docker-compose.yaml i docker-compose-push.yaml es troben en una carpeta, es crea automàticament una única xarxa virtual.
Descripció dels components. Aquest és un fitxer més avançat que s'encarrega de la col·lecció de components. Què hi ha de remarcable aquí? Aquí presentem el component equilibrador.
Aquesta és una imatge de Docker ja feta que executa nginx i una aplicació que escolta al sòcol Docker. Dinàmic, a mesura que s'encenen i s'apaguen els contenidors, regenera la configuració nginx. Distribuïm el maneig de components per noms de domini de tercer nivell.
Per a l'entorn de desenvolupament, utilitzem el domini .dev - api.informer.dev. Les aplicacions amb un domini .dev estan disponibles a la màquina local del desenvolupador.
A més, les configuracions es transfereixen a cada projecte i tots els projectes es llancen junts al mateix temps.
Gràficament, resulta que el client és el nostre navegador o alguna eina amb la qual fem peticions a l'equilibrador.
L'equilibrador de noms de domini determina amb quin contenidor contactar.
Pot ser nginx, que dóna a l'administrador JS. Pot ser nginx, que proporciona l'API, o fitxers estàtics, que es donen a nginx en forma de càrregues d'imatges.
El diagrama mostra que els contenidors estan connectats per una xarxa virtual i s'amaguen darrere d'un servidor intermediari.
A la màquina del desenvolupador, podeu accedir al contenidor coneixent la IP, però en principi no la fem servir. Pràcticament no hi ha necessitat d'accés directe.
Quin exemple cal mirar per acoblar la vostra aplicació? Al meu entendre, un bon exemple és la imatge oficial de Docker per a MySQL.
És bastant desafiant. Hi ha moltes versions. Però la seva funcionalitat permet cobrir moltes necessitats que poden sorgir en el procés de desenvolupament posterior. Si dediqueu temps i descobriu com interactua tot, crec que no tindreu cap problema en l'autoimplementació.
Hub.docker.com normalment conté enllaços a github.com, que conté dades en brut directament a partir de les quals podeu crear la imatge vosaltres mateixos.
A més, en aquest repositori hi ha un script docker-endpoint.sh, que s'encarrega de la inicialització inicial i del processament posterior del llançament de l'aplicació.
També en aquest exemple, hi ha la possibilitat de configurar mitjançant variables d'entorn. En definir una variable d'entorn quan s'executa un únic contenidor o mitjançant docker-compose, podem dir que hem d'establir una contrasenya buida perquè docker pugui arrelar a MySQL o el que vulguem.
Hi ha una opció per crear una contrasenya aleatòria. Diem que necessitem un usuari, hem de posar una contrasenya per a l'usuari i hem de crear una base de dades.
En els nostres projectes, hem unificat lleugerament el Dockerfile, responsable de la inicialització. Allà el vam corregir a les nostres necessitats per fer-lo només una extensió dels drets d'usuari que utilitza l'aplicació. Això ens va permetre crear una base de dades des de la consola de l'aplicació més endavant. Les aplicacions Ruby tenen una ordre per crear, modificar i suprimir bases de dades.
Aquest és un exemple de com és una versió específica de MySQL a github.com. Podeu obrir el Dockerfile i veure com està passant la instal·lació allà.
docker-endpoint.sh és l'script responsable del punt d'entrada. Durant la inicialització inicial, calen alguns passos de preparació i totes aquestes accions es realitzen només a l'script d'inicialització.
Passem a la segona part.
Per emmagatzemar els codis font, hem canviat a gitlab. Aquest és un sistema bastant potent que té una interfície visual.
Un dels components de Gitlab és Gitlab CI. Us permet descriure una seqüència d'ordres que després s'utilitzaran per organitzar un sistema de lliurament de codi o executar proves automàtiques.
Xerrada Gitlab CI 2 - informe del club Ruby Russia - força detallat i potser us interessarà.
Ara veurem què és necessari per activar Gitlab CI. Per iniciar Gitlab CI, només hem de posar el fitxer .gitlab-ci.yml a l'arrel del projecte.
Aquí descrivim que volem executar una seqüència d'estats com una prova, desplegar.
Executem scripts que criden directament a docker-compose per crear la nostra aplicació. Aquest és només un exemple de backend.
A continuació, diem que cal fer migracions per canviar la base de dades i fer proves.
Si els scripts s'executen correctament i no retornen cap codi d'error, el sistema passa a la segona etapa del desplegament.
L'etapa de desplegament està implementada actualment per a l'escenificació. No vam organitzar un reinici sense temps d'inactivitat.
Apaguem a la força tots els contenidors i, després, tornem a aixecar tots els contenidors, recollits en la primera etapa durant la prova.
Estem executant per a la variable d'entorn actual les migracions de bases de dades escrites pels desenvolupadors.
Hi ha una nota que això només s'aplica a la branca mestra.
En canviar altres branques no s'executa.
És possible organitzar els llançaments per oficines.
Per organitzar-ho encara més, hem d'instal·lar Gitlab Runner.
Aquesta utilitat està escrita en Golang. És un fitxer únic, com és habitual al món Golang, que no requereix cap dependència.
A l'inici, registrem el Gitlab Runner.
Obtenim la clau a la interfície web de Gitlab.
A continuació, cridem l'ordre d'inicialització a la línia d'ordres.
Configura Gitlab Runner de manera interactiva (Shell, Docker, VirtualBox, SSH)
El codi de Gitlab Runner s'executarà a cada commit, depenent de la configuració .gitlab-ci.yml.
Com es veu visualment a Gitlab a la interfície web. Després d'haver connectat GItlab CI, tenim una bandera que mostra l'estat de la construcció en aquest moment.
Veiem que fa 4 minuts es va fer un commit, que va superar totes les proves i no va causar cap problema.
Podem mirar més de prop les construccions. Aquí veiem que ja han passat dos estats. Estat de les proves i estat de desplegament a la posada en escena.
Si fem clic a una compilació específica, hi haurà una sortida de consola de les ordres que es van executar en el procés segons .gitlab-ci.yml.
Així és el nostre historial de productes. Veiem que hi va haver intents reeixits. Quan s'envien les proves, no es passa al pas següent i el codi d'escenificació no s'actualitza.
Quines tasques hem resolt a la posada en escena quan vam implementar Docker? El nostre sistema consta de components i hem tingut la necessitat de reiniciar-nos, només una part dels components que s'han actualitzat al repositori, i no tot el sistema.
Per fer-ho, vam haver de trencar-ho tot en carpetes separades.
Després de fer això, vam tenir un problema amb el fet que Docker-compose crea el seu propi espai de xarxa per a cada pare i no veu els components del veí.
Per desplaçar-nos, hem creat manualment la xarxa a Docker. Es va escriure a Docker-compose que utilitzeu aquesta xarxa per a aquest projecte.
Així, cada component que comença amb aquesta malla veu components en altres parts del sistema.
El següent problema és dividir la posada en escena en diversos projectes.
Ja que perquè tot això quedi bonic i el més proper possible a la producció, és bo fer servir el port 80 o 443, que s'utilitza a tot arreu de la WEB.
Com ho hem resolt? Hem assignat un Gitlab Runner a tots els projectes principals.
Gitlab us permet executar diversos Gitlab Runners distribuïts, que simplement agafaran totes les tasques al seu torn d'una manera caòtica i les executaran.
Perquè no tinguem casa, hem limitat el grup dels nostres projectes a un Gitlab Runner, que fa front sense problemes amb els nostres volums.
Vam traslladar nginx-proxy a un script d'inici independent i vam afegir quadrícules per a tots els projectes.
El nostre projecte té una graella i l'equilibrador té diverses graelles per noms de projecte. Pot proxy més per noms de domini.
Les nostres sol·licituds arriben a través del domini del port 80 i es resolen en un grup de contenidors que serveix aquest domini.
Quins altres problemes hi havia? Això és el que tots els contenidors s'executen com a root per defecte. Aquesta és l'arrel desigual a l'amfitrió arrel del sistema.
Tanmateix, si entreu al contenidor, serà root i el fitxer que creem en aquest contenidor obtindrà drets d'arrel.
Si el desenvolupador va entrar al contenidor i va fer algunes ordres allà que generen fitxers i després va deixar el contenidor, llavors té un fitxer al seu directori de treball al qual no té accés.
Com es pot resoldre? Podeu afegir usuaris que estaran al contenidor.
Quins problemes van sorgir quan vam afegir l'usuari?
En crear un usuari, sovint no tenim el mateix ID de grup (UID) i ID d'usuari (GID).
Per resoldre aquest problema al contenidor, utilitzem usuaris amb ID 1000.
En el nostre cas, això va coincidir amb el fet que gairebé tots els desenvolupadors utilitzen el sistema operatiu Ubuntu. I a Ubuntu, el primer usuari té un ID de 1000.
Tenim plans?
Llegiu la documentació de Docker. El projecte es desenvolupa activament, la documentació està canviant. Les dades que es van rebre fa dos o tres mesos ja s'estan quedant obsoletes.
Alguns dels problemes que hem resolt probablement ja estiguin resolts per mitjans estàndard.
Així que ja vull anar més enllà per anar directament a l'orquestració.
Un exemple és el mecanisme integrat de Docker anomenat Docker Swarm, que surt de la caixa. Vull executar alguna cosa en producció basada en la tecnologia Docker Swarm.
Els contenidors de desove fan que sigui inconvenient treballar amb troncs. Ara els troncs estan aïllats. Estan repartits per contenidors. Una de les tasques és facilitar l'accés als registres mitjançant la interfície web.
Font: www.habr.com