Primer, una mica de teoria. Què ha passat ?
En paraules senzilles, aquest document està dissenyat per simplificar el desenvolupament d'aplicacions SaaS, ajudant a informar els desenvolupadors i els enginyers de DevOps sobre els problemes i pràctiques que es troben amb més freqüència en el desenvolupament d'aplicacions modernes.
El document va ser creat pels desenvolupadors de la plataforma Heroku.
L'aplicació Twelve-Factor es pot aplicar a aplicacions escrites en qualsevol llenguatge de programació i utilitzant qualsevol combinació de serveis de suport (bases de dades, cues de missatges, memòria cau, etc.).
Breument sobre els factors en què es basa aquesta metodologia:
- Base de codi – Una base de codi rastrejada en el control de versions – múltiples desplegaments
- Dependències – Declarar i aïllar de manera explícita les dependències
- Configuració – Desa la configuració en temps d'execució
- Serveis de suport – Considereu els serveis de suport com a recursos de complement
- Construir, alliberar, executar – Separar estrictament les etapes de muntatge i d'execució
- Процессы – Executeu l'aplicació com un o més processos sense estat
- Enllaç de port – Serveis d'exportació mitjançant l'enllaç de ports
- Paral·lelisme – Escala la teva aplicació mitjançant processos
- Disposabilitat - Maximitzeu la fiabilitat amb un inici ràpid i un apagat net
- Paritat desenvolupament/operació d'aplicacions – Mantingueu els vostres entorns de desenvolupament, posada en escena i producció tan semblants com sigui possible
- Enregistrament – Veure el registre com un flux d'esdeveniments
- Tasques d'administració – Realitzar tasques d'administració/gestió mitjançant processos ad hoc
Podeu obtenir més informació sobre els 12 factors als recursos següents:
- - lectura obligada
- - Traducció oficial
- - una nova mirada als 12 factors amb l'objectiu de millorar-los.
Què és el desplegament Blau-Verd?
El desplegament blau-verd és un mètode per lliurar una aplicació a producció de tal manera que el client final no veu cap canvi per la seva part. En altres paraules, desplegar una aplicació amb zero temps d'inactivitat.
L'esquema clàssic BG Deploy s'assembla al que es mostra a la imatge següent.
- Al principi hi ha 2 servidors físics amb absolutament el mateix codi, aplicació, projecte, i hi ha un encaminador (equilibrador).
- El router dirigeix inicialment totes les sol·licituds a un dels servidors (verd).
- En el moment en què necessiteu tornar a llançar, tot el projecte s'actualitza en un altre servidor (blau), que actualment no està processant cap sol·licitud.
- Després que el codi estigui activat blau servidor està completament actualitzat, l'encaminador rep una ordre per canviar verd en blau servidor.
- Ara tots els clients veuen el resultat del codi que s'executa blau servidor.
- Durant algun temps, verd el servidor serveix com a còpia de seguretat en cas de desplegament no satisfactori blau servidor i en cas de fallada i errors, l'encaminador torna a canviar el flux d'usuari verd servidor amb l'antiga versió estable i el codi nou s'envia per a la seva revisió i prova.
- I al final del procés, s'actualitza de la mateixa manera verd servidor. I després d'actualitzar-lo, l'encaminador torna a canviar el flux de sol·licituds verd servidor.
Tot es veu molt bé i a primera vista no hi hauria d'haver cap problema.
Però com que vivim al món modern, l'opció amb commutació física tal com indica l'esquema clàssic no ens convé. Enregistreu la informació de moment, hi tornarem més endavant.
Mal i bon consell
renúncia: Els exemples següents mostren les utilitats/metodologies que faig servir, podeu utilitzar absolutament qualsevol alternativa amb funcions similars.
La majoria dels exemples es creuaran d'una manera o altra amb el desenvolupament web (això és una sorpresa), amb PHP i Docker.
Els paràgrafs següents proporcionen una descripció pràctica senzilla de l'ús de factors utilitzant exemples específics; si voleu obtenir més teoria sobre aquest tema, seguiu els enllaços anteriors a la font original.
1. Base de codi
Utilitzeu FTP i FileZilla per carregar fitxers als servidors d'un en un, no emmagatzemeu el codi enlloc més que al servidor de producció.
El projecte ha de tenir sempre una única base de codi, és a dir, tot el codi prové d'una anar repositori. Els servidors (producció, posada en escena, prova1, prova2...) utilitzen codi de branques d'un dipòsit comú. D'aquesta manera aconseguim la coherència del codi.
2. Dependències
Baixeu totes les biblioteques en carpetes directament a l'arrel del projecte. Feu actualitzacions simplement transferint el codi nou a la carpeta amb la versió actual de la biblioteca. Instal·leu totes les utilitats necessàries directament al servidor amfitrió on s'executen 20 serveis més.
Un projecte ha de tenir sempre una llista clarament comprensible de dependències (per dependències també entenc l'entorn). Totes les dependències s'han de definir i aïllar explícitament.
Prenguem com a exemple compositor и estibador.
compositor — un gestor de paquets que us permet instal·lar biblioteques en PHP. Composer us permet especificar versions de manera estricta o laxa, i definir-les explícitament. Hi pot haver 20 projectes diferents al servidor i cadascun tindrà una llista personal de paquets i biblioteques independents de l'altre.
estibador — una utilitat que us permet definir i aïllar l'entorn en què s'executarà l'aplicació. En conseqüència, igual que amb el compositor, però més a fons, podem determinar amb què funciona l'aplicació. Seleccioneu una versió específica de PHP, instal·leu només els paquets necessaris perquè el projecte funcioni, sense afegir res addicional. I el més important, sense interferir amb els paquets i l'entorn de la màquina amfitriona i altres projectes. És a dir, tots els projectes del servidor que s'executen mitjançant Docker poden utilitzar absolutament qualsevol conjunt de paquets i un entorn completament diferent.
3. Configuració
Emmagatzema les configuracions com a constants directament al codi. Constants separades per al servidor de prova, separades per a la producció. Vinculeu el funcionament de l'aplicació en funció de l'entorn directament a la lògica de negoci del projecte utilitzant les construccions if else.
Configuracions - aquesta és l'única manera que els desplegaments del projecte han de ser diferents. Idealment, les configuracions s'han de passar a través de variables d'entorn (env vars).
És a dir, fins i tot si emmagatzemeu diversos fitxers de configuració .config.prod .config.local i els canvieu el nom en el moment del desplegament a .config (la configuració principal des de la qual l'aplicació llegeix les dades), aquest no serà l'enfocament adequat, ja que en aquest cas, la informació de les configuracions estarà disponible públicament per a tots els desenvolupadors d'aplicacions i les dades del servidor de producció es veuran compromeses. Totes les configuracions s'han d'emmagatzemar directament al sistema de desplegament (CI/CD) i generar-se per a diferents entorns amb diferents valors necessaris per a un entorn concret en el moment del desplegament.
4. Serveis de tercers
Estar estrictament lligat a l'entorn, utilitzar connexions diferents per als mateixos serveis en determinats entorns.
De fet, aquest punt se solapa fortament amb el de les configuracions, ja que sense aquest punt no es poden fer dades de configuració normals i, en general, la capacitat de configurar es reduirà a res.
Totes les connexions a serveis externs, com ara servidors de cues, bases de dades, serveis de memòria cau, han de ser iguals tant per a l'entorn local com per a l'entorn de producció o de tercers. En altres paraules, en qualsevol moment, canviant la cadena de connexió, puc substituir les trucades a la base #1 per la base #2 sense canviar el codi de l'aplicació. O, mirant cap endavant, com a exemple, quan escaleu el servei, no haureu d'especificar la connexió de cap manera especial per a un servidor de memòria cau addicional.
5. Construir, alliberar, executar
Teniu només la versió final del codi al servidor, sense cap possibilitat de revertir la versió. No cal omplir espai al disc. Qualsevol que pensi que pot llançar codi en producció amb un error és un mal programador!
Totes les etapes del desplegament han d'estar separades entre si.
Tingueu l'oportunitat de retrocedir. Fes llançaments amb còpies antigues de l'aplicació (ja muntades i llestes per a la batalla) desades en accés ràpid, de manera que en cas d'error puguis restaurar la versió antiga. És a dir, condicionalment hi ha una carpeta comunicats i carpeta corrent, i després d'un desplegament i muntatge correctes de la carpeta corrent enllaçat per un enllaç simbòlic al nou llançament que hi ha dins comunicats amb el nom convencional del número de llançament.
Aquí és on recordem el desplegament Blue-Green, que us permet no només canviar entre codi, sinó també canviar entre tots els recursos i fins i tot entorns amb la possibilitat de revertir-ho tot.
6. Processos
Emmagatzema les dades de l'estat de l'aplicació directament dins de l'aplicació. Utilitzeu sessions a la memòria RAM de la pròpia aplicació. Utilitzeu el màxim possible de compartir entre serveis de tercers. Confieu en el fet que l'aplicació només pot tenir un procés i no permet escalar.
Pel que fa a les sessions, emmagatzema les dades només en una memòria cau controlada per serveis de tercers (memcached, redis), de manera que encara que tinguis 20 processos d'aplicació en execució, qualsevol d'ells, havent accedit a la memòria cau, podrà continuar treballant amb el client en el mateix estat en què l'usuari estava treballant amb l'aplicació en un altre procés. Amb aquest enfocament, resulta que no importa quantes còpies de serveis de tercers utilitzeu, tot funcionarà amb normalitat i sense problemes d'accés a les dades.
7. Enquadernació de port
Només el servidor web hauria de saber com treballar amb serveis de tercers. O millor encara, instal·leu serveis de tercers directament dins del servidor web. Per exemple, com a mòdul PHP a Apache.
Tots els vostres serveis han de ser accessibles entre ells mitjançant l'accés a alguna adreça i port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), és a dir, des de nginx puc accedir tant a php-fpm com a postgres, i de php-fpm a postgres i nginx i, de fet, des de cada servei puc accedir a un altre servei. D'aquesta manera, la viabilitat d'un servei no està lligada a la viabilitat d'un altre servei.
8. Paral·lelisme
Treballeu amb un procés, en cas contrari, diversos processos no es podran portar bé entre ells!
Deixeu espai per escalar. L'eixam Docker és fantàstic per a això.
Docker Swarm és una eina per crear i gestionar grups de contenidors entre diferents màquines i un munt de contenidors a la mateixa màquina.
Mitjançant l'eixam, puc determinar quants recursos destinaré a cada procés i quants processos del mateix servei llançaré, i l'equilibrador intern, rebent dades en un port determinat, les enviarà automàticament als processos. Així, veient que la càrrega al servidor ha augmentat, puc afegir més processos, reduint així la càrrega en determinats processos.
9. Disposabilitat
No utilitzeu cues per treballar amb processos i dades. Eliminar un procés hauria d'afectar tota l'aplicació. Si un servei cau, tot cau.
Cada procés i servei es pot desactivar en qualsevol moment i això no hauria d'afectar altres serveis (per descomptat, això no vol dir que el servei no estigui disponible per a un altre servei, però que un altre servei no s'apagarà després d'aquest). Tots els processos s'han d'acabar amb gràcia, de manera que quan s'acabin, no es danyin dades i el sistema funcionarà correctament la propera vegada que l'engegueu. És a dir, fins i tot en el cas d'una terminació d'emergència, les dades no s'han de danyar (el mecanisme de transacció és adequat aquí, les consultes a la base de dades només funcionen en grups, i si almenys una consulta del grup falla o s'executa amb un error, llavors cap altra consulta del grup falla finalment).
10. Paritat desenvolupament/operació d'aplicacions
La producció, la posada en escena i la versió local de l'aplicació han de ser diferents. En producció utilitzem el framework Yii Lite, i localment Yii, perquè funcioni més ràpid en producció!
En realitat, tots els desplegaments i treballs amb codi haurien de ser en un entorn gairebé idèntic (no estem parlant de maquinari físic). A més, qualsevol empleat de desenvolupament hauria de poder desplegar el codi a la producció si cal, i no un departament de devops especialment entrenat, que només gràcies a una força especial pot portar l'aplicació a producció.
Docker també ens ajuda amb això. Si s'observen tots els punts anteriors, l'ús de docker farà que el procés de desplegament de l'entorn tant en producció com a la màquina local introdueixi una o dues ordres.
11. Registres
Escrivim registres a fitxers i bases de dades! No netegem fitxers i bases de dades dels registres. Anem a comprar un disc dur amb 9000 Peta bytes i està bé.
Tots els registres s'han de considerar com un flux d'esdeveniments. L'aplicació en si no hauria d'estar involucrada en el processament dels registres. Els registres s'han de sortir a stdout o enviats mitjançant un protocol com ara udp, de manera que treballar amb registres no creï cap problema per a l'aplicació. Graylog és bo per a això. Graylog que rep tots els registres mitjançant udp (aquest protocol no requereix esperar una resposta sobre la recepció correcta del paquet) no interfereix de cap manera amb l'aplicació i només s'ocupa de l'estructuració i processament dels registres. La lògica de l'aplicació no canvia per treballar amb aquests enfocaments.
12. Tasques d'administració
Per actualitzar dades, bases de dades, etc., utilitzeu un punt final creat per separat a l'API; executar-lo 2 vegades seguides farà que tot es dupliqui. Però no ets estúpid, no faràs clic dos cops i no necessitem la migració.
Totes les tasques d'administració s'han de realitzar en el mateix entorn que tot el codi, a nivell de llançament. És a dir, si hem de canviar l'estructura de la base de dades, aleshores no ho farem manualment canviant els noms de les columnes i afegint-ne de nous mitjançant algunes eines visuals de gestió de bases de dades. Per a aquestes coses, creem scripts separats: migracions, que s'executen a tot arreu i en tots els entorns de la mateixa manera amb un resultat comú i comprensible. Per a totes les altres tasques, com ara omplir el projecte amb dades, s'han d'utilitzar metodologies similars.
Exemple d'implementació en PHP, Laravel, Laradock, Docker-Compose
PS Tots els exemples es van fer a MacOS. La majoria d'ells també són adequats per a Linux. Usuaris de Windows, perdoneu-me, però fa temps que no treballo amb Windows.
Imaginem una situació en què no tinguem cap versió de PHP instal·lada al nostre ordinador i res de res.
Instal·leu les últimes versions de docker i docker-compose. (es pot trobar a Internet)
docker -v &&
docker-compose -v
1. Posa
git clone https://github.com/Laradock/laradock.git &&
ls
Pel que fa a Laradock, diré que és una cosa molt xula, que conté molts contenidors i coses auxiliars. Però no recomanaria utilitzar Laradock com a tal sense modificacions en la producció a causa de la seva redundància. És millor crear els vostres propis contenidors a partir d'exemples a Laradock, això estarà molt més optimitzat, perquè ningú necessita tot el que hi ha al mateix temps.
2. Configureu Laradock per executar la nostra aplicació.
cd laradock &&
cp env-example .env
2.1. Obriu el directori habr (la carpeta principal on es clona laradock) en algun editor. (En el meu cas PHPStorm)
En aquesta fase només donem un nom al projecte.
2.2. Inicieu la imatge de l'espai de treball. (En el vostre cas, les imatges trigaran un temps a construir-se)
L'espai de treball és una imatge especialment preparada per treballar amb el marc en nom del desenvolupador.
Entrem dins del recipient utilitzant
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instal·lació de Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Després de la instal·lació, comprovem si s'ha creat el directori amb el projecte i kill compose.
ls
exit
docker-compose down
2.5. Tornem a PHPStorm i establim el camí correcte a la nostra aplicació laravel al fitxer .env.
3. Afegiu tot el codi a Git.
Per fer-ho, crearem un repositori a Github (o en qualsevol altre lloc). Anem al directori habr del terminal i executem el codi següent.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Comprovem si tot està en ordre.
Per comoditat, recomano utilitzar alguna interfície visual per a Git, en el meu cas és així . (aquí hi ha un enllaç de referència)
4. Llencem!
Abans de començar, assegureu-vos que no hi hagi res penjat als ports 80 i 443.
docker-compose up -d nginx php-fpm
Així, el nostre projecte consta de 3 serveis diferents:
- nginx - servidor web
- php-fpm - php per rebre peticions d'un servidor web
- espai de treball - php per a desenvolupadors
De moment, hem aconseguit que hem creat una aplicació que compleix 4 punts sobre 12, a saber:
1. Base de codi — tot el codi es troba en un sol dipòsit (nota petita: podria ser correcte afegir docker dins del projecte laravel, però això no és important).
2. Dependències - Totes les nostres dependències estan escrites explícitament a application/composer.json i a cada Dockerfile de cada contenidor.
3. Serveis de suport — Cadascun dels serveis (php-fom, nignx, workspace) viu la seva pròpia vida i està connectat des de l'exterior i quan es treballa amb un servei, l'altre no es veurà afectat.
4. Процессы — cada servei és un procés. Cadascun dels serveis no manté l'estat intern.
5. Enllaç de port
docker ps
Com podem veure, cada servei funciona al seu propi port i és accessible per a tots els altres serveis.
6. Paral·lelisme
Docker ens permet generar diversos processos dels mateixos serveis amb un equilibri automàtic de càrrega entre ells.
Parem els contenidors i passem-los per la bandera —escala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Com podem veure, s'han creat còpies del contenidor php-fpm. No hem de canviar res en treballar amb aquest contenidor. També seguim accedint-hi al port 9000 i Docker ens regula la càrrega entre contenidors.
7. Disposabilitat - Cada recipient es pot matar sense danyar l'altre. Aturar o reiniciar el contenidor no afectarà el funcionament de l'aplicació durant els llançaments posteriors. Cada contenidor també es pot aixecar en qualsevol moment.
8. Paritat desenvolupament/operació d'aplicacions - tots els nostres entorns són iguals. En executar el sistema en un servidor en producció, no haureu de canviar res a les vostres ordres. Tot es basarà en Docker de la mateixa manera.
9. Enregistrament — tots els registres d'aquests contenidors es transmeten en temps real i són visibles a la consola de Docker. (en aquest cas, de fet, amb altres envasos casolans, potser no serà així si no en tens cura)
docker-compose logs -f
Però hi ha un problema en què els valors predeterminats en PHP i Nginx també escriuen registres en un fitxer. Per complir amb els 12 factors, és necessari desactivar escrivint registres en un fitxer a les configuracions de cada contenidor per separat.
Docker també ofereix la possibilitat d'enviar registres no només a stdout, sinó també a coses com ara graylog, que he esmentat anteriorment. I dins de graylog, podem operar els registres com vulguem i la nostra aplicació no ho notarà de cap manera.
10. Tasques d'administració — Laravel resol totes les tasques d'administració gràcies a l'eina artesanal exactament com voldrien els creadors de l'aplicació de 12 factors.
Com a exemple, mostraré com s'executen algunes ordres.
Entrem al contenidor.
docker-compose exec workspace bash
php artisan list
Ara podem utilitzar qualsevol comanda. (tingueu en compte que no hem configurat la base de dades i la memòria cau, de manera que la meitat de les ordres no s'executaran correctament, perquè estan dissenyades per funcionar amb la memòria cau i la base de dades).
11. Configuracions i 12. Construir, alliberar, executar
Volia dedicar aquesta part al desplegament blau-verd, però va resultar ser massa extensa per a aquest article. Escriuré un article a part sobre això.
En poques paraules, el concepte es basa en sistemes CI/CD com Jenkins и Gitlab CI. En tots dos, podeu establir variables d'entorn associades a un entorn específic. En conseqüència, en aquesta situació, es complirà el punt c Configuracions.
I el punt sobre Construir, alliberar, executar es resol mitjançant funcions integrades amb el nom Canonada.
Canonada permet dividir el procés de desplegament en moltes etapes, destacant les etapes de muntatge, llançament i execució. També a Pipeline, podeu crear còpies de seguretat i, de fet, qualsevol cosa. Aquesta és una eina amb un potencial il·limitat.
El codi de l'aplicació és a .
No oblideu inicialitzar el submòdul quan cloneu aquest dipòsit.
PS: Tots aquests enfocaments es poden utilitzar amb qualsevol altra utilitat i llenguatge de programació. El més important és que l'essència no difereix.
Font: www.habr.com