Dalgunha maneira, nun momento dado, decidín escribir un artigo sobre a entrega en forma de contedores Docker e paquetes deb, pero cando comecei, por algún motivo leváronme atrás aos tempos afastados dos primeiros ordenadores persoais e mesmo das calculadoras. En xeral, en lugar de comparacións secas de docker e deb, obtivemos estas reflexións sobre o tema da evolución, que presento para a súa consideración.
Calquera produto, sexa cal sexa, debe chegar dalgún xeito aos servidores do produto, debe configurarse e lanzarse. Diso tratará este artigo.
Pensarei nun contexto histórico, "o que vexo é sobre o que canto", o que vin cando comecei a escribir código e o que observo agora, o que nós mesmos estamos usando neste momento e por que. O artigo non pretende ser un estudo completo, bótanse en falta algúns puntos, esta é a miña visión persoal do que foi e do que é agora.
Entón, nos bos tempos... o primeiro método de entrega que atopei foron cintas de casete de gravadoras. Tiña un ordenador BK-0010.01...
A era das calculadoras
Non, houbo un momento aínda anterior, tamén houbo unha calculadora и .
Entón, cando tiven , entón a forma de transferir o programa era un anaco de papel normal nunha caixa na que estaba escrito un programa que, se é necesario, para executalo manualmente, escribíase na calculadora. Se queres xogar (si, incluso esta calculadora antediluviana tiña xogos) - senta e introduce o programa na calculadora. Por suposto, cando a calculadora foi apagada, o programa desapareceu no esquecemento. Ademais dos códigos de calculadora escritos persoalmente en papel, os programas foron publicados nas revistas “Radio” e “Tecnoloxía para a mocidade”, e tamén foron publicados en libros daquela época.
A seguinte modificación foi unha calculadora , xa ten algunha aparencia de almacenamento de datos non volátiles. Agora o xogo ou o programa non tiña que ser introducido manualmente, pero despois de realizar uns pases máxicos cos botóns, cargábase por si mesmo.
O tamaño do programa máis grande da calculadora era de 105 pasos e o tamaño da memoria permanente no MK-52 era de 512 pasos.
Por certo, se hai fans destas calculadoras que están lendo este artigo, no proceso de escribir o artigo atopei tanto un emulador de calculadora para Android como programas para el. Adiante ao pasado!
Unha pequena digresión sobre MK-52 (de Wikipedia)
O MK-52 voou ao espazo na sonda Soyuz TM-7. Suponse que se utilizaba para calcular a traxectoria de aterraxe no caso de que fallase o ordenador de a bordo.
Desde 52, o MK-1988 coa unidade de expansión de memoria Elektronika-Astro foi subministrado aos buques da Mariña como parte dun kit de computación de navegación.
Os primeiros ordenadores persoais
Volvamos aos tempos . Está claro que alí había máis memoria, e escribir código desde un papel xa non era unha opción (aínda que ao principio fixen precisamente iso, porque simplemente non había outro medio). As casetes de audio para gravadoras están a converterse no principal medio de almacenamento e entrega de software.
O almacenamento nun casete era xeralmente en forma de un ou dous ficheiros binarios, todo o demais estaba contido no seu interior. A fiabilidade era moi baixa, tiven que gardar 2-3 copias do programa. Os tempos de carga tamén foron decepcionantes, e os entusiastas experimentaron con diferentes codificacións de frecuencia para superar estas deficiencias. Daquela, eu mesmo aínda non estaba involucrado no desenvolvemento profesional de software (sen contar os programas sinxelos en BASIC), polo que, por desgraza, non vos contarei en detalle como estaba todo disposto no interior. O feito de que o ordenador só tivese RAM na súa maior parte determinou a simplicidade do esquema de almacenamento de datos.
A aparición de medios de almacenamento fiables e grandes
Máis tarde apareceron os disquetes, simplificouse o proceso de copia e aumentou a fiabilidade.
Pero a situación cambia drasticamente só cando aparecen almacenamentos locais suficientemente grandes en forma de discos duros.
O tipo de entrega está cambiando fundamentalmente: aparecen programas de instalación que xestionan o proceso de configuración do sistema, así como a limpeza despois da eliminación, xa que os programas non só se len na memoria, senón que xa se copian no almacenamento local, desde o que cómpre ser capaz de borrar cousas innecesarias se é necesario.
Ao mesmo tempo, aumenta a complexidade do software subministrado.
O número de ficheiros na entrega aumenta duns poucos a centos e miles, os conflitos entre as versións da biblioteca e outras alegrías comezan cando diferentes programas usan os mesmos datos.
Daquela, a existencia de Linux aínda non estaba aberta para min; vivín no mundo de MS DOS e, máis tarde, de Windows, e escribín en Borland Pascal e Delphi, ás veces mirando cara C++. Moita xente usaba InstallShield para entregar produtos daquela. , que resolveu con bastante éxito todas as tarefas asignadas de implantación e configuración do software.
Era de Internet
Aos poucos, a complexidade dos sistemas de software vaise facendo aínda máis complexa; dende as aplicacións monolitos e de escritorio hai unha transición a sistemas distribuídos, clientes lixeiros e microservizos. Agora cómpre configurar non só un programa, senón un conxunto deles, para que funcionen todos xuntos.
O concepto cambiou por completo, chegou Internet, chegou a era dos servizos na nube. Ata agora, só na fase inicial, en forma de sitios web, ninguén soñou especialmente con servizos. pero supuxo un punto de inflexión tanto no desenvolvemento como na entrega de aplicacións.
En canto a min, notei que nese momento houbo un cambio nas xeracións de desenvolvedores (ou só no meu entorno), e tiña a sensación de que todos os vellos métodos de entrega foron esquecidos nun momento e todo comezou desde o mesmo momento. comezo: toda a entrega comezou a facerse guións de xeonllos e chamábaa orgullosamente "Entrega continua". De feito, comezou un período de caos, no que o vello se esquece e non se usa, e o novo simplemente non existe.
Lembro os tempos nos que na nosa empresa na que traballaba daquela (non o vou nomear), en lugar de construír a través de formiga (maven aínda non era popular ou non existía en absoluto), a xente simplemente recollía tarros no IDE e comprometíase con serenidade. en SVN. En consecuencia, a implantación consistiu en recuperar o ficheiro de SVN e copialo vía SSH na máquina desexada. É tan sinxelo e torpe.
Ao mesmo tempo, a entrega de sitios sinxelos en PHP fíxose dun xeito moi primitivo simplemente copiando o ficheiro corrixido vía FTP na máquina de destino. Ás veces non era así: o código editábase en directo no servidor do produto, e era especialmente elegante se había copias de seguridade nalgún lugar.
Paquetes RPM e DEB
Por outra banda, co desenvolvemento de Internet, os sistemas tipo UNIX comezaron a gañar cada vez máis popularidade, en particular, foi nese momento cando descubrín RedHat Linux 6, aproximadamente 2000. Naturalmente, tamén había certos medios para entregar software; segundo Wikipedia, RPM como principal xestor de paquetes apareceu xa en 1995, na versión de RedHat Linux 2.0. E desde entón e ata hoxe, o sistema foi entregado en forma de paquetes RPM e estivo a existir e desenvolverse con bastante éxito.
As distribucións da familia Debian seguiron un camiño similar e implementaron a entrega en forma de paquetes deb, que permaneceu sen cambios ata hoxe.
Os xestores de paquetes permítenche entregar os propios produtos de software, configuralos durante o proceso de instalación, xestionar dependencias entre diferentes paquetes, eliminar produtos e limpar elementos innecesarios durante o proceso de desinstalación. Eses. na súa meirande parte, iso é todo o que fai falta, polo que duraron varias décadas practicamente sen cambios.
A computación na nube engadiu a instalación aos xestores de paquetes non só desde medios físicos, senón tamén desde repositorios na nube, pero fundamentalmente pouco cambiou.
Paga a pena notar que actualmente hai algúns movementos para afastarse de deb e cambiar a paquetes instantáneos, pero máis sobre iso máis tarde.
Entón, esta nova xeración de desenvolvedores na nube, que non coñecían nin DEB nin RPM, tamén creceu lentamente, adquiriu experiencia, os produtos fixéronse máis complexos e necesitáronse algúns métodos de entrega máis razoables que FTP, scripts bash e manualidades similares para estudantes.
E aquí é onde entra en escena Docker, unha especie de mestura de virtualización, delimitación de recursos e método de entrega. Agora está de moda e xuvenil, pero é necesario para todo? É esta unha panacea?
Polas miñas observacións, moitas veces non se propón Docker como unha opción razoable, senón simplemente porque, por unha banda, fálase del na comunidade, e quen o propoñen só o sabe. Por outra banda, na súa maioría calan sobre os bos e vellos sistemas de envasado: existen e fan o seu traballo en silencio e desapercibidos. En tal situación, realmente non hai outra opción - a elección é obvia - Docker.
Tentarei compartir a miña experiencia sobre como implementamos Docker e o que pasou como resultado.
Guións autoescritos
Inicialmente, había scripts bash que despregaban arquivos jar nas máquinas necesarias. Este proceso foi xestionado por Jenkins. Isto funcionou con éxito, xa que o propio arquivo jar xa é un conxunto que contén clases, recursos e mesmo configuración. Se o metes todo ao máximo, expandilo nun guión non é o máis difícil que necesitas
Pero os guións teñen varias desvantaxes:
- Os guións adoitan escribirse con présa e, polo tanto, son tan primitivos que só conteñen un escenario no mellor dos casos. Isto vese facilitado polo feito de que o programador está interesado nunha entrega rápida e un guión normal require o investimento dunha cantidade decente de recursos
- como consecuencia do punto anterior, os scripts non conteñen procedementos de desinstalación
- ningún procedemento de actualización establecido
- Cando aparece un novo produto, cómpre escribir un novo script
- sen apoio á dependencia
Por suposto, podes escribir un guión sofisticado, pero, como escribín anteriormente, este é o tempo de desenvolvemento, e non menos importante, e, como sabemos, sempre non hai tempo suficiente.
Todo isto, obviamente, limita o ámbito de aplicación deste método de implantación só aos sistemas máis sinxelos. Chegou o momento de cambiar isto.
Estivador
Nalgún momento, comezaron a chegar ata nós medios recén acuñados, fervendo de ideas e delirando polo estibador. Ben, bandeira en man - imos facelo! Houbo dous intentos. Ambos non tiveron éxito, digamos, debido a grandes ambicións, pero a falta de experiencia real. Era necesario forzalo e rematalo por calquera medio posible? É improbable: o equipo debe evolucionar ata o nivel necesario antes de poder utilizar as ferramentas adecuadas. Ademais, ao utilizar imaxes de Docker xa preparadas, moitas veces atopámonos co feito de que a rede non funcionaba correctamente (o que puido ser debido á humidade do propio Docker) ou que era difícil ampliar os contedores alleos.
Que inconvenientes atopamos?
- Problemas de rede en modo ponte
- É inconveniente ver os rexistros nun contedor (se non se almacenan por separado no sistema de ficheiros da máquina host)
- ElasticSearch ocasionalmente conxélase de forma estraña dentro do recipiente, o motivo non se determinou, o recipiente é oficial
- É necesario usar unha cuncha dentro dun recipiente: todo está moi depurado, non hai ferramentas coñecidas
- Gran tamaño dos envases recollidos - custosos de almacenar
- Debido ao gran tamaño dos contedores, é difícil admitir varias versións
- Tempo de construción máis longo, a diferenza doutros métodos (scripts ou paquetes deb)
Por outra banda, por que é peor despregar un servizo Spring en forma de arquivo jar a través da mesma deb? É realmente necesario o illamento dos recursos? Paga a pena perder ferramentas convenientes do sistema operativo enchendo un servizo nun contedor moi reducido?
Como a práctica demostrou, en realidade isto non é necesario, o paquete deb é suficiente no 90% dos casos.
Cando falla o bo e vello deb e cando realmente necesitamos docker?
Para nós, isto foi implementar servizos en Python. Moitas bibliotecas necesarias para a aprendizaxe automática e non incluídas na distribución estándar do sistema operativo (e o que había eran versións incorrectas), pirateos con configuracións, a necesidade de diferentes versións para diferentes servizos que viven no mesmo sistema host levou a isto, que a única forma razoable de entregar esta mestura nuclear era o estibador. A intensidade laboral de montar un contedor docker resultou ser inferior á idea de empaquetalo todo en paquetes de deb separados con dependencias e, de feito, ninguén no seu sano juicio asumiría isto.
O segundo punto no que pensamos usar Docker é implantar servizos mediante o esquema de implantación azul-verde. Pero aquí quero conseguir un aumento gradual da complexidade: primeiro, constrúense paquetes deb e despois constrúese un contedor docker a partir deles.
Empaquetar paquetes
Volvemos aos paquetes rápidos. Apareceron oficialmente por primeira vez en Ubuntu 16.04. A diferenza dos paquetes deb e rpm habituais, snap leva todas as dependencias. Por unha banda, isto permítelle evitar conflitos de bibliotecas, por outra banda, o paquete resultante é de maior tamaño. Ademais, isto tamén pode afectar á seguridade do sistema: no caso de entrega instantánea, todos os cambios nas bibliotecas incluídas deben ser supervisados polo programador que crea o paquete. En xeral, non todo é tan sinxelo e a felicidade universal non vén de usalos. Pero, con todo, esta é unha alternativa completamente razoable se o mesmo Docker se usa só como ferramenta de empaquetado e non para a virtualización.
Como resultado, agora usamos paquetes deb e contedores docker nunha combinación razoable, que, quizais, nalgúns casos substituiremos por paquetes instantáneos.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Que usas para a entrega?
-
Guións autoescritos
-
Copia manualmente a FTP
-
paquetes deb
-
paquetes rpm
-
paquetes a presión
-
Docker-imaxes
-
Imaxes de máquinas virtuais
-
Clonar todo o disco duro
-
monicreque
-
ansible
-
Outro
Votaron 109 usuarios. 32 usuarios abstivéronse.
Fonte: www.habr.com