Primeiro, un pouco de teoría. Que pasou ?
En palabras sinxelas, este documento está deseñado para simplificar o desenvolvemento de aplicacións SaaS, axudando a informar aos desenvolvedores e enxeñeiros de DevOps sobre os problemas e prácticas que se atopan con máis frecuencia no desenvolvemento de aplicacións modernas.
O documento foi creado polos desenvolvedores da plataforma Heroku.
A aplicación Twelve-Factor pódese aplicar a aplicacións escritas en calquera linguaxe de programación e utilizando calquera combinación de servizos de apoio (bases de datos, filas de mensaxes, caché, etc.).
Brevemente sobre os factores nos que se basea esta metodoloxía:
- Base de código – Unha base de código rastrexada no control de versións: varias implementacións
- Dependencias – Declarar e illar de forma explícita as dependencias
- Configuración - Gardar a configuración en tempo de execución
- Servizos de apoio – Considere os servizos de apoio como recursos complementarios
- Construír, liberar, executar – Separar estrictamente as fases de montaxe e execución
- Os procesos – Executar a aplicación como un ou máis procesos sen estado
- Unión de portos – Servizos de exportación a través da vinculación portuaria
- Concorrencia – Escala a túa aplicación mediante procesos
- Dispoñibilidade - Maximiza a fiabilidade cun inicio rápido e un apagado limpo
- Paridade desenvolvemento/operación de aplicacións – Mantén os teus ambientes de desenvolvemento, posta en escena e produción o máis similares posible
- Rexistro - Ver o rexistro como un fluxo de eventos
- Tarefas de administración – Realizar tarefas de administración/xestión mediante procesos ad hoc
Podes obter máis información sobre os 12 factores a partir dos seguintes recursos:
- - unha lectura obrigada
- - tradución oficial
- - unha nova mirada aos 12 factores co obxectivo de melloralos.
Que é a implantación Blue-Green?
A implantación azul-verde é un método para entregar unha aplicación produción de tal xeito que o cliente final non vexa ningún cambio pola súa parte. Noutras palabras, implementar unha aplicación con cero tempo de inactividade.
O esquema clásico BG Deploy parece o que se mostra na imaxe de abaixo.
- Ao comezo hai 2 servidores físicos con absolutamente o mesmo código, aplicación, proxecto e hai un enrutador (equilibrador).
- O router dirixe inicialmente todas as solicitudes a un dos servidores (verde).
- No momento no que necesites lanzar de novo, todo o proxecto actualízase noutro servidor (azul), que non está a procesar ningunha solicitude.
- Despois de activar o código azul servidor está completamente actualizado, o enrutador recibe un comando para cambiar verde en azul servidor.
- Agora todos os clientes ven o resultado do código que se executa azul servidor.
- Durante algún tempo, verde o servidor serve como copia de seguridade en caso de implantación non exitosa en azul servidor e en caso de fallo e erros, o router cambia o fluxo de usuario de novo verde servidor coa versión estable antiga e o novo código envíase para revisión e proba.
- E ao final do proceso, actualízase do mesmo xeito verde servidor. E despois de actualizalo, o enrutador volve cambiar o fluxo de solicitudes verde servidor.
Todo parece moi bo e a primeira vista non debería haber ningún problema con el.
Pero xa que vivimos no mundo moderno, a opción con conmutación física como se indica no esquema clásico non nos convén. Grava a información polo momento, volveremos a ela máis tarde.
Mal e bo consello
retratação: Os exemplos de abaixo mostran as utilidades/metodoloxías que uso, podes usar absolutamente calquera alternativa con funcións similares.
A maioría dos exemplos cruzaranse dun xeito ou doutro co desenvolvemento web (isto é unha sorpresa), con PHP e Docker.
Os parágrafos seguintes ofrecen unha descrición práctica sinxela do uso de factores utilizando exemplos específicos; se queres obter máis teoría sobre este tema, siga as ligazóns anteriores á fonte orixinal.
1. Base de código
Use FTP e FileZilla para cargar ficheiros aos servidores un a un, non almacene o código en ningún lugar que non sexa no servidor de produción.
O proxecto debe ter sempre unha única base de código, é dicir, todo o código provén dun só ir repositorio. Os servidores (produción, posta en escena, test1, test2...) usan código de ramas dun repositorio común. Deste xeito conseguimos a coherencia do código.
2. Dependencias
Descarga todas as bibliotecas dos cartafoles directamente na raíz do proxecto. Fai actualizacións simplemente transferindo o novo código ao cartafol coa versión actual da biblioteca. Instala todas as utilidades necesarias directamente no servidor host onde se están executando 20 servizos máis.
Un proxecto debe ter sempre unha lista de dependencias claramente comprensible (por dependencias refírome tamén ao medio ambiente). Todas as dependencias deben estar definidas e illadas de forma explícita.
Poñamos como exemplo compositor и Estivador.
compositor — un xestor de paquetes que che permite instalar bibliotecas en PHP. Composer permítelle especificar versións de forma estrita ou libre e definilas de forma explícita. Pode haber 20 proxectos diferentes no servidor e cada un terá unha lista persoal de paquetes e bibliotecas independentes do outro.
Estivador — unha utilidade que lle permite definir e illar o ambiente no que se executará a aplicación. En consecuencia, do mesmo xeito que con compositor, pero máis a fondo, podemos determinar con que funciona a aplicación. Seleccione unha versión específica de PHP, instale só os paquetes necesarios para que o proxecto funcione, sen engadir nada extra. E o máis importante, sen interferir cos paquetes e o ambiente da máquina host e outros proxectos. É dicir, todos os proxectos do servidor que se executan a través de Docker poden usar absolutamente calquera conxunto de paquetes e un ambiente completamente diferente.
3. Configuración
Almacene as configuracións como constantes directamente no código. Constantes separadas para o servidor de proba, separadas para a produción. Vincula o funcionamento da aplicación dependendo do entorno directamente na lóxica de negocio do proxecto utilizando if else constrúe.
Configuracións - Esta é a única forma en que as implantacións do proxecto deberían diferir. Idealmente, as configuracións deberían pasarse a través de variables de ambiente (env vars).
É dicir, aínda que almacene varios ficheiros de configuración .config.prod .config.local e cambie o nome deles no momento da implantación a .config (a configuración principal desde a que a aplicación le os datos), este non será o enfoque correcto, xa que neste caso, a información das configuracións estará dispoñible publicamente para todos os desenvolvedores de aplicacións e os datos do servidor de produción veranse comprometidos. Todas as configuracións deben almacenarse directamente no sistema de implantación (CI/CD) e xerarse para diferentes contornas con diferentes valores necesarios para un entorno específico no momento da implantación.
4. Servizos de terceiros
Estar estritamente ligado ao medio ambiente, utilizar conexións diferentes para os mesmos servizos en determinadas contornas.
De feito, este punto se solapa fortemente co punto sobre as configuracións, xa que sen este punto non se poden facer datos de configuración normais e, en xeral, a capacidade de configurar caerá en nada.
Todas as conexións a servizos externos, como servidores de colas, bases de datos, servizos de almacenamento en caché, deben ser iguais tanto para o ambiente local como para o ambiente de terceiros/produción. Noutras palabras, en calquera momento, cambiando a cadea de conexión, podo substituír as chamadas á base #1 pola base #2 sen cambiar o código da aplicación. Ou, mirando cara adiante, como exemplo, ao escalar o servizo, non terá que especificar a conexión de ningún xeito especial para un servidor de caché adicional.
5. Construír, liberar, executar
Ten só a versión final do código no servidor, sen posibilidade de revertir a versión. Non é necesario encher espazo no disco. Calquera persoa que pense que pode lanzar código en produción cun erro é un mal programador!
Todas as fases de implantación deben estar separadas entre si.
Ten a oportunidade de retroceder. Fai lanzamentos con copias antigas da aplicación (xa montadas e listas para a batalla) gardadas en acceso rápido, para que en caso de erros poidas restaurar a versión antiga. É dicir, condicionalmente hai un cartafol lanzamentos e cartafol actual, e despois da implantación e montaxe exitosas do cartafol actual está ligada por unha ligazón simbólica á nova versión que hai no seu interior lanzamentos co nome convencional do número de lanzamento.
Aquí é onde lembramos a implementación Blue-Green, que che permite non só cambiar entre códigos, senón tamén cambiar entre todos os recursos e mesmo ambientes coa posibilidade de retroceder todo.
6. Procesos
Almacena os datos do estado da aplicación directamente na propia aplicación. Usa sesións na memoria RAM da propia aplicación. Use o máximo posible de compartición entre servizos de terceiros. Confía no feito de que a aplicación só pode ter un proceso e non permite escalar.
En canto ás sesións, almacena os datos só nunha caché controlada por servizos de terceiros (memcached, redis), polo que aínda que teñas 20 procesos de aplicación en execución, calquera deles, tendo acceso á caché, poderá seguir traballando co cliente en o mesmo estado no que o usuario estaba a traballar coa aplicación noutro proceso. Con este enfoque, resulta que non importa cantas copias de servizos de terceiros use, todo funcionará con normalidade e sen problemas de acceso aos datos.
7. Vinculación de portos
Só o servidor web debería saber traballar con servizos de terceiros. Ou mellor aínda, instala servizos de terceiros directamente dentro do servidor web. Por exemplo, como un módulo PHP en Apache.
Todos os seus servizos deben ser accesibles entre si a través do acceso a algún enderezo e porto (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), é dicir, desde nginx podo acceder tanto a php-fpm como a postgres, e de php-fpm a postgres e nginx e en realidade desde cada servizo podo acceder a outro servizo. Deste xeito, a viabilidade dun servizo non está ligada á viabilidade doutro servizo.
8. Paralelismo
Traballa cun proceso, se non, varios procesos non poderán levarse ben entre si.
Deixa espazo para escalar. Docker swarm é xenial para iso.
Docker Swarm é unha ferramenta para crear e xestionar clústeres de contedores entre máquinas diferentes e un grupo de contedores na mesma máquina.
Usando swarm, podo determinar cantos recursos asignarei a cada proceso e cantos procesos do mesmo servizo lanzarei, e o equilibrador interno, que recibe datos nun porto determinado, enviaraos automaticamente aos procesos. Así, ao ver que a carga no servidor aumentou, podo engadir máis procesos, reducindo así a carga en determinados procesos.
9. Dispoñibilidade
Non use colas para traballar con procesos e datos. Eliminar un proceso debería afectar a toda a aplicación. Se un servizo cae, todo cae.
Cada proceso e servizo pódese desactivar en calquera momento e isto non debería afectar a outros servizos (por suposto, isto non significa que o servizo non estea dispoñible para outro servizo, senón que outro servizo non se desactivará despois deste). Todos os procesos deben finalizarse con gracia, de xeito que cando se rematen, non se dane ningún dato e o sistema funcionará correctamente a próxima vez que o acenda. É dicir, mesmo no caso dunha terminación de emerxencia, os datos non deberían ser danados (o mecanismo de transacción é adecuado aquí, as consultas na base de datos só funcionan en grupos, e se polo menos unha consulta do grupo falla ou se executa cun erro, entón ningunha outra consulta do grupo falla de feito).
10. Paridade desenvolvemento/operación de aplicacións
A produción, a posta en escena e a versión local da aplicación deben ser diferentes. Na produción usamos o marco Yii Lite, e localmente Yii, para que funcione máis rápido na produción.
En realidade, todos os despregamentos e traballos con código deberían realizarse nun ambiente case idéntico (non estamos a falar de hardware físico). Ademais, calquera empregado de desenvolvemento debería poder implementar o código na produción se é necesario, e non algún departamento de devops especialmente adestrado, que só grazas a unha forza especial pode levar a aplicación á produción.
Docker tamén nos axuda con isto. Se se observan todos os puntos anteriores, o uso de docker fará que o proceso de implantación do ambiente tanto en produción como na máquina local introduza un ou dous comandos.
11. Rexistros
Escribimos rexistros en ficheiros e bases de datos! Non limpamos ficheiros e bases de datos dos rexistros. Imos comprar un disco duro con 9000 Peta bytes e está ben.
Todos os rexistros deben considerarse como un fluxo de eventos. A propia aplicación non debería estar implicada no procesamento dos rexistros. Os rexistros deberían saír a stdout ou enviados a través dun protocolo como udp, para que traballar con rexistros non xere ningún problema para a aplicación. graylog é bo para iso. Graylog recibe todos os rexistros a través de udp (este protocolo non require esperar unha resposta sobre a recepción exitosa do paquete) non interfire coa aplicación de ningún xeito e só se ocupa da estruturación e procesamento dos rexistros. A lóxica da aplicación non cambia para funcionar con tales enfoques.
12. Tarefas de administración
Para actualizar datos, bases de datos, etc., use un punto final creado por separado na API, e executalo 2 veces seguidas provocará que todo se duplique. Pero non es parvo, non fará clic dúas veces e non necesitamos migración.
Todas as tarefas de administración deben realizarse no mesmo entorno que todo o código, a nivel de versión. É dicir, se necesitamos cambiar a estrutura da base de datos, entón non o faremos manualmente cambiando os nomes das columnas e engadindo outras novas mediante algunhas ferramentas visuais de xestión de bases de datos. Para tales cousas, creamos scripts separados: migracións, que se executan en todas partes e en todos os ambientes da mesma forma cun resultado común e comprensible. Para todas as demais tarefas, como encher o proxecto con datos, deben utilizarse metodoloxías similares.
Exemplo de implementación en PHP, Laravel, Laradock, Docker-Compose
P.S. Todos os exemplos foron feitos en MacOS. A maioría deles tamén son axeitados para Linux. Usuarios de Windows, perdóenme, pero hai tempo que non traballo con Windows.
Imaxinemos unha situación na que non temos ningunha versión de PHP instalada no noso PC e nada de nada.
Instala as versións máis recentes de docker e docker-compose. (Isto pódese atopar en Internet)
docker -v &&
docker-compose -v
1. Poñer
git clone https://github.com/Laradock/laradock.git &&
ls
Respecto de Laradock, direi que é unha cousa moi chula, que contén moitos recipientes e cousas auxiliares. Pero non recomendaría usar Laradock como tal sen modificacións na produción debido á súa redundancia. É mellor crear os teus propios contedores baseados en exemplos en Laradock, isto estará moito máis optimizado, porque ninguén necesita todo o que hai ao mesmo tempo.
2. Configure Laradock para executar a nosa aplicación.
cd laradock &&
cp env-example .env
2.1. Abre o directorio habr (o cartafol principal no que se clona Laradock) nalgún editor. (No meu caso PHPStorm)
Nesta fase só lle damos un nome ao proxecto.
2.2. Inicia a imaxe do espazo de traballo. (No teu caso, as imaxes tardarán en construírse)
Workspace é unha imaxe especialmente preparada para traballar co framework en nome do programador.
Entramos dentro do recipiente usando
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instalación de Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Despois da instalación, comprobamos se o directorio co proxecto foi creado e kill compose.
ls
exit
docker-compose down
2.5. Volvamos a PHPStorm e establecemos o camiño correcto para a nosa aplicación laravel no ficheiro .env.
3. Engade todo o código a Git.
Para iso, crearemos un repositorio en Github (ou en calquera outro lugar). Imos ao directorio habr do terminal e executemos o seguinte código.
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
Comprobamos se todo está en orde.
Por comodidade, recomendo usar algunha interface visual para Git, no meu caso é . (aquí tes unha ligazón de referencia)
4. Imos lanzar!
Antes de comezar, asegúrese de que non hai nada colgado nos portos 80 e 443.
docker-compose up -d nginx php-fpm
Así, o noso proxecto consta de 3 servizos distintos:
- nginx - servidor web
- php-fpm - php para recibir solicitudes dun servidor web
- espazo de traballo - php para desenvolvedores
Polo momento, conseguimos que creamos unha aplicación que cumpre 4 puntos sobre 12, a saber:
1. Base de código — todo o código está nun repositorio (nota pequena: pode ser correcto engadir docker dentro do proxecto laravel, pero isto non é importante).
2. Dependencias - Todas as nosas dependencias están escritas explícitamente en application/composer.json e en cada Dockerfile de cada contedor.
3. Servizos de apoio — Cada un dos servizos (php-fom, nignx, workspace) vive a súa propia vida e está conectado desde fóra e cando se traballa cun servizo, o outro non se verá afectado.
4. Os procesos - cada servizo é un proceso. Cada un dos servizos non mantén o estado interno.
5. Unión de portos
docker ps
Como podemos ver, cada servizo funciona no seu propio porto e é accesible para todos os demais servizos.
6. Concorrencia
Docker permítenos xerar varios procesos dos mesmos servizos cun balance de carga automático entre eles.
Paremos os contedores e pasemos pola bandeira --escala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Como podemos ver, creáronse copias do contedor php-fpm. Non necesitamos cambiar nada ao traballar con este contedor. Tamén seguimos accedendo a el no porto 9000 e Docker regula a carga entre contedores para nós.
7. Dispoñibilidade - cada recipiente pódese matar sen prexudicar ao outro. Deter ou reiniciar o contedor non afectará o funcionamento da aplicación durante os lanzamentos posteriores. Cada recipiente tamén se pode levantar en calquera momento.
8. Paridade desenvolvemento/operación de aplicacións - todos os nosos ambientes son iguais. Ao executar o sistema nun servidor en produción, non terás que cambiar nada nos teus comandos. Todo estará baseado en Docker do mesmo xeito.
9. Rexistro — todos os rexistros destes contenedores van á transmisión e son visibles na consola de Docker. (neste caso, de feito, con outros envases caseiros, isto pode non ser o caso se non o coida)
docker-compose logs -f
Pero hai un problema en que os valores predeterminados en PHP e Nginx tamén escriben rexistros nun ficheiro. Para cumprir os 12 factores, é necesario desconectar escribir rexistros nun ficheiro nas configuracións de cada contedor por separado.
Docker tamén ofrece a posibilidade de enviar rexistros non só a stdout, senón tamén a cousas como graylog, que mencionei anteriormente. E dentro de graylog, podemos operar os rexistros como queiramos e a nosa aplicación non notará isto de ningún xeito.
10. Tarefas de administración — todas as tarefas de administración son resoltas por laravel grazas á ferramenta artesanal exactamente como lles gustaría aos creadores da aplicación de 12 factores.
Como exemplo, mostrarei como se executan algúns comandos.
Entramos no recipiente.
docker-compose exec workspace bash
php artisan list
Agora podemos usar calquera comando. (ten en conta que non configuramos a base de datos e a caché, polo que a metade dos comandos non se executarán correctamente, porque están deseñados para funcionar coa caché e a base de datos).
11. Configuracións e 12. Construír, liberar, executar
Quería dedicar esta parte á implementación azul-verde, pero resultou ser demasiado extensa para este artigo. Vou escribir un artigo separado sobre isto.
En poucas palabras, o concepto está baseado en sistemas CI/CD como Jenkins и Gitlab CI. En ambos, pode establecer variables de ambiente asociadas a un ambiente específico. En consecuencia, nesta situación, cumprirase o punto c Configuracións.
E o punto sobre Construír, liberar, executar resólvese mediante funcións integradas co nome Oleoduto.
Oleoduto permite dividir o proceso de implantación en moitas fases, destacando as fases de montaxe, liberación e execución. Tamén en Pipeline, podes crear copias de seguridade e, de feito, calquera cousa. Esta é unha ferramenta cun potencial ilimitado.
O código da aplicación está en .
Non esquezas inicializar o submódulo ao clonar este repositorio.
P.D.: Todos estes enfoques pódense usar con calquera outra utilidade e linguaxe de programación. O principal é que a esencia non difire.
Fonte: www.habr.com