Suxiro que lea a transcrición do informe de Alexander Sigachev de Inventos "Proceso de desenvolvemento e proba con Docker + Gitlab CI"
Aqueles que están empezando a implementar o proceso de desenvolvemento e proba baseado en Docker + Gitlab CI adoitan facer preguntas básicas. Por onde comezar? Como organizar? Como probar?
Este informe é bo porque fala de forma estruturada sobre o proceso de desenvolvemento e proba mediante Docker e Gitlab CI. O informe en si é de 2017. Creo que deste informe podes recoller os conceptos básicos, a metodoloxía, a idea e a experiencia de uso.
A quen lle importa, por favor debaixo do gato.
Chámome Alexander Sigachev. Traballo para Inventos. Vouvos contar a miña experiencia usando Docker e como o imos implementando aos poucos nos proxectos da empresa.
Tema do informe: Proceso de desenvolvemento mediante Docker e Gitlab CI.
Esta é a miña segunda charla sobre Docker. No momento do primeiro informe, utilizabamos Docker só no desenvolvemento en máquinas para desenvolvedores. O número de empregados que utilizaron Docker foi de entre 2 e 3 persoas. Pouco a pouco foi collendo experiencia e fomos un pouco máis alá. Ligazón ao noso .
Que haberá neste informe? Compartiremos a nosa experiencia sobre que rastrillos recollemos, que problemas solucionamos. Non era bonito en todas partes, pero permitiunos seguir adiante.
O noso lema: dockerize todo o que temos nas mans.
Que problemas estamos resolvendo?
Cando unha empresa ten varios equipos, o programador é un recurso compartido. Hai etapas nas que un programador é retirado dun proxecto e entregado a outro durante algún tempo.
Para que un programador entenda rapidamente, ten que descargar o código fonte do proxecto e lanzar un ambiente o máis rápido posible, o que lle permitirá avanzar aínda máis na resolución dos problemas deste proxecto.
Normalmente, se comezas de cero, hai pouca documentación no proxecto. Só os vellos teñen información sobre como configuralo. Os empregados configuran o seu lugar de traballo por si mesmos nun ou dous días. Para acelerar isto, usamos Docker.
O seguinte motivo é a estandarización da configuración en Desenvolvemento. Segundo a miña experiencia, os desenvolvedores sempre toman a iniciativa. En cada quinto caso, introdúcese un dominio personalizado, por exemplo vasya.dev. Sentado ao meu lado está o meu veciño Petya, cuxo dominio é petya.dev. Desenvolven un sitio web ou algún compoñente do sistema usando este nome de dominio.
Cando o sistema crece e estes nomes de dominio comezan a incluírse na configuración, xorde un conflito nos contornos de Desenvolvemento e a ruta do sitio é reescrita.
O mesmo ocorre coa configuración da base de datos. Algunhas persoas non se preocupan pola seguridade e traballan cun contrasinal de root baleiro. Na fase de instalación, MySQL pediu a alguén un contrasinal e o contrasinal resultou ser 123. A miúdo ocorre que a configuración da base de datos estaba cambiando constantemente dependendo do compromiso do programador. Alguén corrixiu, alguén non corrixiu a configuración. Houbo trucos cando puxemos algunha configuración de proba .gitignore e cada desenvolvedor tiña que instalar a base de datos. Isto dificultou o proceso de inicio. Entre outras cousas, cómpre lembrar a base de datos. Debe inicializarse a base de datos, rexistrarse un contrasinal, rexistrarse un usuario, crear un sinal, etc.
Outro problema son as diferentes versións das bibliotecas. Adoita ocorrer que un desenvolvedor traballa en diferentes proxectos. Hai un proxecto Legacy, que comezou hai cinco anos (a partir de 2017 - nota do editor). Ao principio comezamos con MySQL 5.5. Tamén hai proxectos modernos nos que estamos tentando implementar versións máis modernas de MySQL, por exemplo 5.7 ou anteriores (en 2017 - nota do editor)
Calquera persoa que traballe con MySQL sabe que estas bibliotecas levan dependencias. É bastante problemático executar 2 bases de datos xuntos. Como mínimo, é problemático conectar clientes antigos á nova base de datos. Isto á súa vez dá lugar a varios problemas.
O seguinte problema é cando un desenvolvedor traballa nunha máquina local, usa recursos locais, ficheiros locais, RAM local. Toda a interacción á hora de desenvolver unha solución aos problemas realízase no marco do feito de que funciona nunha máquina. Un exemplo sería cando temos servidores de backend en Production 3, e o programador garda ficheiros no directorio raíz e desde alí nginx leva os ficheiros para responder á solicitude. Cando tal código entra en produción, resulta que o ficheiro está presente nun dos 3 servidores.
Actualmente estase a desenvolver a dirección de microservizos. Cando dividimos as nosas grandes aplicacións nalgúns pequenos compoñentes que interactúan entre si. Isto permítelle seleccionar tecnoloxías para unha pila de tarefas específica. Isto tamén permite dividir o traballo e a área de responsabilidade entre os desenvolvedores.
Un desenvolvedor frontend, que se desenvolve en JS, practicamente non ten influencia no backend. O desenvolvedor backend, pola súa banda, desenvolve, no noso caso, Ruby on Rails e non interfire con Frondend. A interacción realízase mediante a API.
Como extra, mediante Docker puidemos reciclar recursos en Staging. Cada proxecto, polas súas especificidades, requiría determinadas configuracións. Fisicamente, era necesario asignar ou ben un servidor virtual e configuralos por separado, ou ben dividir algún tipo de ambiente variable e os proxectos podían influír entre si, dependendo da versión das bibliotecas.
Ferramentas. Que usamos?
- Docker en si. Un Dockerfile describe as dependencias dunha única aplicación.
- Docker-compose é un paquete que reúne varias das nosas aplicacións Docker.
- Usamos GitLab para almacenar o código fonte.
- Usamos GitLab-CI para a integración do sistema.
O informe consta de dúas partes.
A primeira parte indicarache como executar Docker nas máquinas dos desenvolvedores.
A segunda parte falará sobre como interactuar con GitLab, como realizamos probas e como implementamos a Staging.
Docker é unha tecnoloxía que permite (utilizando un enfoque declarativo) describir os compoñentes necesarios. Este é un exemplo de Dockerfile. Aquí declaramos que estamos herdando a imaxe oficial de Docker de Ruby: 2.3.0. Contén instalada a versión 2.3 de Ruby. Instalamos as bibliotecas de montaxe necesarias e NodeJS. Describimos que estamos creando un directorio /app. Asignamos o directorio da aplicación como directorio de traballo. Neste directorio colocamos o mínimo necesario Gemfile e Gemfile.lock. Despois construímos proxectos que instalan esta imaxe de dependencia. Indicamos que o contedor estará listo para escoitar no porto externo 3000. O último comando é o comando que inicia directamente a nosa aplicación. Se executamos o comando de execución do proxecto, a aplicación tentará executar e executar o comando especificado.
Este é un exemplo mínimo de ficheiro docker-compose. Neste caso, mostramos que existe unha conexión entre dous recipientes. Isto está directamente no servizo de base de datos e servizo web. As nosas aplicacións web requiren na maioría dos casos algún tipo de base de datos como backend para almacenar datos. Xa que usamos MySQL, o exemplo é con MySQL, pero nada nos impide usar algunha outra base de datos (PostgreSQL, Redis).
Tomamos a imaxe de MySQL 5.7.14 sen cambios da fonte oficial do hub Docker. Recollemos a imaxe responsable da nosa aplicación web do directorio actual. Durante o primeiro lanzamento, recolle unha imaxe para nós. Despois executa o comando que estamos a executar aquí. Se volvemos, veremos que o comando de inicio foi definido a través de Puma. Puma é un servizo escrito en Ruby. No segundo caso anulamos. Este comando pode ser arbitrario dependendo das nosas necesidades ou tarefas.
Tamén describimos que necesitamos reenviar o porto na nosa máquina anfitrión de desenvolvedores de 3000 a 3000 porto de contedores. Isto faise automaticamente usando iptables e o seu propio mecanismo, que está directamente incrustado en Docker.
O programador pode, como antes, acceder a calquera enderezo IP dispoñible, por exemplo, 127.0.0.1 enderezo IP local ou externo da máquina.
A última liña di que o contedor web depende do contenedor db. Cando chamamos ao contedor web para que se lance, docker-compose lanzará primeiro a base de datos por nós. Xa no inicio da base de datos (de feito, despois do lanzamento do contedor! Isto non garante a preparación da base de datos) lanzará a nosa aplicación, o noso backend.
Isto permítenos evitar erros cando a base de datos non está activa e permítenos aforrar recursos cando paramos o contedor da base de datos, liberando así recursos para outros proxectos.
Que nos proporciona usar a dockerización de bases de datos nun proxecto? Gravamos a versión de MySQL para todos os desenvolvedores. Isto permítelle evitar algúns erros que poden ocorrer cando as versións diverxen, cando cambian a sintaxe, a configuración e os axustes predeterminados. Isto permítelle especificar un nome de host común para a base de datos, o inicio de sesión e o contrasinal. Afastámonos do zoo de nomes e conflitos nos ficheiros de configuración que existían antes.
Temos a oportunidade de usar unha configuración máis óptima para o contorno de Desenvolvemento, que será diferente da por defecto. MySQL está configurado por defecto para máquinas débiles e o seu rendemento fóra da caixa é moi baixo.
Docker permítelle usar o intérprete Python, Ruby, NodeJS e PHP da versión desexada. Deshacémonos da necesidade de utilizar algún tipo de xestor de versións. Anteriormente, utilizábase un paquete rpm para Ruby, que permitía cambiar a versión dependendo do proxecto. Grazas ao contedor Docker, tamén che permite migrar o código e versiónlo sen problemas xunto coas dependencias. Non temos ningún problema para entender a versión tanto do intérprete como do código. Para actualizar a versión, cómpre baixar o contedor antigo e subir o novo. Se algo sae mal, podemos baixar o novo recipiente, subir o vello.
Despois de construír a imaxe, os contedores tanto en Desenvolvemento como en Produción serán os mesmos. Isto é especialmente certo para grandes instalacións.
En Frontend usamos JavaScipt e NodeJS.
Agora temos o noso último proxecto en ReacJS. O programador lanzou todo o contido do contedor e desenvolveuse usando a recarga en quente.
A continuación, lánzase a tarefa de montar JavaScipt e envíase o código estáticamente ensamblado a través de nginx, aforrando recursos.
Aquí proporcionei un diagrama do noso último proxecto.
Que problemas resolveches? Tiñamos a necesidade de construír un sistema co que interactúan os dispositivos móbiles. Reciben datos. Unha das posibilidades é enviar notificacións push a este dispositivo.
Que fixemos por isto?
Dividimos a aplicación nos seguintes compoñentes: unha parte administrativa en JS, un backend que funciona a través dunha interface REST en Ruby on Rails. O backend interactúa coa base de datos. O resultado que se xera entrégase ao cliente. O panel de administración interactúa co backend e a base de datos a través dunha interface REST.
Tamén tivemos que enviar notificacións push. Antes disto, tiñamos un proxecto no que se implantaba un mecanismo que se encargaba de entregar as notificacións ás plataformas móbiles.
Desenvolvemos o seguinte esquema: o operador do navegador interactúa co panel de administración, o panel de administración interactúa co backend, a tarefa é enviar notificacións Push.
As notificacións push interactúan con outro compoñente implementado en NodeJS.
Constrúense colas e envíanse notificacións segundo o seu propio mecanismo.
Aquí debuxáronse dúas bases de datos. Actualmente, usando Docker, utilizamos 2 bases de datos independentes que de ningún xeito están conectadas entre si. Ademais de que teñen unha rede virtual común, e os datos físicos almacénanse en diferentes directorios na máquina do programador.
O mesmo pero en números. A reutilización do código é importante aquí.
Se antes falabamos de reutilizar código en forma de bibliotecas, neste exemplo o noso servizo, que responde ás notificacións Push, reutilizase como un servidor completo. Ofrece unha API. E o noso novo desenvolvemento interactúa con el.
Nese momento estabamos a usar a versión 4 de NodeJS. Agora (en 2017 - nota do editor) nos nosos últimos desenvolvementos usamos a versión 7 de NodeJS. Non hai ningún problema en novos compoñentes para implicar novas versións das bibliotecas.
Se é necesario, pode refactorizar e aumentar a versión NodeJS do servizo de notificación Push.
E se podemos manter a compatibilidade da API, entón será posible substituíla por outros proxectos que se usaban anteriormente.
Que necesitas para engadir Docker? Engadimos un Dockerfile ao noso repositorio, que describe as dependencias necesarias. Neste exemplo, os compoñentes están divididos loxicamente. Este é o kit mínimo para un programador backend.
Ao crear un novo proxecto, creamos un Dockerfile e describimos o ecosistema necesario (Python, Ruby, NodeJS). En docker-compose, describe a dependencia necesaria: a base de datos. Describimos que necesitamos unha base de datos de tal ou tal versión, para almacenar datos alí e alí.
Usamos un terceiro recipiente separado con nginx para servir contido estático. É posible subir imaxes. O backend colócaos nun volume preparado previamente, que tamén se monta nun contedor con nginx, que proporciona datos estáticos.
Para almacenar a configuración de nginx e mysql, engadimos un cartafol Docker no que almacenamos as configuracións necesarias. Cando un desenvolvedor fai un clon git dun repositorio na súa máquina, xa ten un proxecto preparado para o desenvolvemento local. Non hai dúbida sobre que porto ou configuración aplicar.
A continuación temos varios compoñentes: admin, info-API, notificacións push.
Para lanzar todo isto, creamos outro repositorio chamado dockerized-app. Actualmente usamos varios repositorios para cada compoñente. Son simplemente diferentes loxicamente: en GitLab parece un cartafol, pero na máquina do programador parece un cartafol para un proxecto específico. Un nivel máis abaixo están os compoñentes que se combinarán.
Este é un exemplo do contido de dockerized-app. Tamén colocamos aquí un directorio Docker, no que enchemos as configuracións necesarias para as interaccións de todos os compoñentes. Hai un README.md que describe brevemente como lanzar o proxecto.
Aquí aplicamos dous ficheiros docker-compose. Isto faise para poder lanzarse por etapas. Cando un desenvolvedor traballa co núcleo, non precisa notificacións push, simplemente inicia o ficheiro docker-compose e, en consecuencia, gárdanse os recursos.
Se é necesario integrar as notificacións push, lánzanse docker-compose.yaml e docker-compose-push.yaml.
Dado que docker-compose.yaml e docker-compose-push.yaml están no cartafol, créase automaticamente unha única rede virtual.
Descrición dos compoñentes. Este é un ficheiro máis avanzado que se encarga de recoller compoñentes. Que hai de notable aquí? Aquí presentamos o compoñente equilibrador.
Esta é unha imaxe de Docker preparada que executa nginx e unha aplicación que escoita o socket Docker. Dinámico, a medida que se activan e desactivan os contedores, rexenérase a configuración de nginx. Distribuímos o manexo de compoñentes mediante nomes de dominio de terceiro nivel.
Para o contorno de desenvolvemento usamos o dominio .dev - api.informer.dev. As aplicacións cun dominio .dev están dispoñibles na máquina local do programador.
A continuación, as configuracións transfírense a cada proxecto e todos os proxectos lánzanse xuntos ao mesmo tempo.
Se o representamos graficamente, resulta que o cliente é o noso navegador ou algún tipo de ferramenta coa que facemos solicitudes ao equilibrador.
O equilibrador determina o contedor ao que se debe acceder en función do nome de dominio.
Pode ser nginx, que proporciona JS ao panel de administración. Isto pódese facer mediante nginx, que proporciona a API, ou ficheiros estáticos, que son proporcionados por nginx en forma de carga de imaxes.
O diagrama mostra que os contedores están conectados a unha rede virtual e ocultos detrás dun proxy.
Na máquina do programador, podes acceder ao contedor coñecendo a IP, pero en principio non usamos esta. Practicamente non hai necesidade de contacto directo.
Que exemplo debo mirar para acoplar a miña aplicación? Na miña opinión, un bo exemplo é a imaxe docker oficial para MySQL.
É bastante complicado. Hai moitas versións. Pero a súa funcionalidade permítelle cubrir moitas necesidades que poidan xurdir no proceso de desenvolvemento. Se tomas o tempo e entendes como interactúa todo, creo que non terás ningún problema para implementalo por ti mesmo.
Hub.docker.com adoita conter ligazóns a github.com, onde se proporcionan datos en bruto directamente desde os que pode crear unha imaxe vostede mesmo.
Ademais neste repositorio hai un script docker-endpoint.sh, que é responsable da inicialización inicial e do procesamento posterior do lanzamento da aplicación.
Tamén neste exemplo existe a posibilidade de configuración mediante variables de ambiente. Ao definir unha variable de ambiente ao executar un único contedor ou mediante docker-compose, podemos dicir que necesitamos establecer un contrasinal baleiro para docker para root en MySQL ou o que queiramos.
Hai unha opción para crear un contrasinal aleatorio. Dicimos que necesitamos un usuario, necesitamos establecer un contrasinal para o usuario e necesitamos crear unha base de datos.
Nos nosos proxectos, unificamos lixeiramente o Dockerfile, que é o responsable da inicialización. Alí axustámolo ás nosas necesidades para simplemente ampliar os dereitos de usuario que utiliza a aplicación. Isto fixo posible simplemente crear unha base de datos desde a consola da aplicación no futuro. As aplicacións Ruby teñen comandos para crear, modificar e eliminar bases de datos.
Este é un exemplo do aspecto dunha versión específica de MySQL en github.com. Podes abrir o Dockerfile e ver como se realiza a instalación alí.
script docker-endpoint.sh responsable do punto de entrada. Durante a inicialización inicial, son necesarias algunhas accións de preparación e todas estas accións están incluídas no script de inicialización.
Pasemos á segunda parte.
Cambiamos a gitlab para almacenar códigos fonte. Este é un sistema bastante potente que ten unha interface visual.
Un dos compoñentes de Gitlab é Gitlab CI. Permítelle describir unha serie de comandos que posteriormente se utilizarán para organizar un sistema de entrega de código ou realizar probas automatizadas.
Informe sobre Gitlab CI 2 — o informe do club Ruby Russia é bastante detallado e pode ser do teu interese.
Agora veremos o que se require para activar Gitlab CI. Para iniciar Gitlab CI, só necesitamos poñer o ficheiro .gitlab-ci.yml na raíz do proxecto.
Aquí describimos que queremos realizar unha secuencia de estados como proba, despregamento.
Executamos scripts que chaman directamente á compilación docker-compose da nosa aplicación. Este é un exemplo só do backend.
A continuación dicimos que é necesario realizar migracións para cambiar a base de datos e realizar probas.
Se os scripts se executan correctamente e non devolven un código de erro, o sistema pasa á segunda fase de implantación.
A fase de implantación está actualmente implementada para a posta en escena. Non organizamos un reinicio sen tempo de inactividade.
Apagamos á forza todos os envases e despois levantamos todos os envases de novo, recollidos na primeira fase durante a proba.
Imos executar as migracións de bases de datos que foron escritas polos desenvolvedores para o ambiente variable actual.
Hai unha nota de que isto só debe aplicarse á rama mestra.
Non funciona cando se cambia outras ramas.
É posible organizar os lanzamentos ao longo das ramas.
Para organizalo aínda máis, necesitamos instalar Gitlab Runner.
Esta utilidade está escrita en Golang. É un ficheiro único como é habitual no mundo Golang, que non require ningunha dependencia.
No inicio rexistramos Gitlab Runner.
Recibimos a chave na interface web de Gitlab.
Despois chamamos ao comando de inicialización na liña de comandos.
Configurando Gitlab Runner en modo de diálogo (Shell, Docker, VirtualBox, SSH)
O código en Gitlab Runner executarase en cada commit dependendo da configuración .gitlab-ci.yml.
Como se ve visualmente en Gitlab na interface web. Despois de conectar GItlab CI, temos unha bandeira que mostra en que estado está a compilación neste momento.
Vemos que hai 4 minutos fíxose un commit que pasou todas as probas e non causou ningún problema.
Podemos ver as construcións con máis detalle. Aquí vemos que xa pasaron dous estados. Estado de proba e estado de implantación na posta en escena.
Se facemos clic nunha compilación específica, haberá saída da consola dos comandos que se lanzaron no proceso segundo .gitlab-ci.yml.
Así é a historia do noso produto. Vemos que houbo intentos exitosos. Cando se envían as probas, non pasan ao seguinte paso e non se actualiza o código de preparación.
Que problemas resolvemos na posta en escena cando implementamos Docker? O noso sistema consta de compoñentes e necesitabamos reiniciar só algúns dos compoñentes que se actualizaron no repositorio, e non todo o sistema.
Para iso, tivemos que separar todo en cartafoles separados.
Despois de facelo, tivemos un problema co feito de que Docker-compose crea o seu propio espazo de rede para cada cartafol e non ve os compoñentes do seu veciño.
Para desprazarnos, creamos a rede manualmente en Docker. En Docker-compose escribiuse que deberías usar esa rede para este proxecto.
Así, cada compoñente que comeza con esta malla ve compoñentes noutras partes do sistema.
O seguinte problema é dividir a posta en escena entre varios proxectos.
Xa que para que todo isto pareza fermoso e o máis próximo posible á produción, é bo usar o porto 80 ou 443, que se usa en todas partes da WEB.
Como solucionamos isto? Asignamos un Gitlab Runner a todos os grandes proxectos.
Gitlab permíteche lanzar varios Gitlab Runners distribuídos, que simplemente levarán todas as tarefas unha a unha nunha orde caótica e executalas.
Para evitar problemas na casa, limitamos o grupo dos nosos proxectos a un Gitlab Runner, que xestiona os nosos volumes sen problemas.
Movemos nginx-proxy a un script de lanzamento separado e escribimos nel as cuadrículas de todos os proxectos.
O noso proxecto ten unha cuadrícula e o equilibrador ten varias cuadrículas baseadas nos nomes dos proxectos. Pode proxy máis por nomes de dominio.
As nosas solicitudes chegan a través do dominio do porto 80 e resólvense a un grupo de contedores que atende este dominio.
Que outros problemas houbo? Isto é o que todos os contedores executan como root por defecto. Este é o servidor raíz desigual do sistema.
Non obstante, se entras no contedor, será root e o ficheiro que creamos neste contedor recibe dereitos de root.
Se un desenvolvedor entrou no contedor e fixo algúns comandos alí que xeraron ficheiros, e logo deixou o contedor, entón no seu directorio de traballo ten un ficheiro ao que non ten acceso.
Como se pode resolver isto? Podes engadir usuarios que estarán no contedor.
Que problemas xurdiron cando engadimos o usuario?
Ao crear un usuario, o ID de grupo (UID) e o ID de usuario (GID) moitas veces non coinciden.
Para solucionar este problema no contedor utilizamos usuarios con ID 1000.
No noso caso, isto coincidiu co feito de que case todos os desenvolvedores usan Ubuntu OS. E no sistema operativo Ubuntu o primeiro usuario ten ID 1000.
Temos plans?
Volve ler a documentación de Docker. O proxecto está a desenvolverse activamente, a documentación está cambiando. Os datos que se obtiveron hai dous ou tres meses van quedando desactualizados aos poucos.
Algúns dos problemas que solucionamos poden ter sido xa resoltos por medios estándar.
Quero moito seguir adiante e pasar directamente á orquestración.
Un exemplo é o mecanismo integrado de Docker chamado Docker Swarm, que sae da caixa. Gustaríame lanzar algo en produción baseado na tecnoloxía Docker Swarm.
Os contedores de desova dificultan o traballo con rexistros. Agora os rexistros están illados. Están espallados en recipientes. Unha das tarefas é facilitar o acceso aos rexistros a través dunha interface web.
Fonte: www.habr.com