Durante mucho tiempo, la compañía Maxnet Systems usó la versión gratuita de VMware - ESXi, comenzando con la versión 5.0, como hipervisor. La versión paga de vSphere ahuyentaba el modelo de licencia, mientras que la versión gratuita tenía una serie de inconvenientes que no estaban disponibles en la versión paga, pero podía soportarlos. Pero cuando en las nuevas versiones de ESXi la nueva interfaz web se negó a funcionar con la anterior, y el monitoreo de los conjuntos RAID dejó de mostrar signos de vida, la compañía decidió buscar una solución más universal y abierta. La compañía ya tenía una buena experiencia y una buena impresión de LXC - Contenedores Linux. Por lo tanto, se hizo evidente que el hipervisor soñado será híbrido y combinará KVM y LXD para diferentes cargas, una continuación evolutiva de LXC. Al buscar información sobre KVM, la empresa se enfrentó a conceptos erróneos, rastrillos y prácticas nocivas, pero las pruebas y el tiempo pusieron todo en su lugar.
Sobre cómo lidiar con el cambio de ESXi a KVM y no conducir una rueda en un rastrillo, le dirá a
Lev Nikolaev (
maniaco ), administrador y desarrollador de sistemas altamente cargados, entrenador de tecnología de la información. Hablemos de la red, repositorios, contenedores, KVM, LXD, LXC, aprovisionamiento y máquinas virtuales convenientes.
Prologo
Identificaremos inmediatamente los pensamientos clave, y luego los analizaremos con más detalle.
Red. Si bien las velocidades de sus interfaces no superan los 1 Gb / s, el puente es suficiente para usted. Tan pronto como quieras exprimir más, te limitará.
Repositorio. Crea un almacenamiento de red compartido. Incluso si no está listo para usar 10 Gbit / s dentro de la red, incluso 1 Gbit / s le dará 125 MB / s de almacenamiento. Para una serie de cargas, esto será suficiente con un margen, y la migración de máquinas virtuales será una cuestión elemental.
Contenedor o KVM? Pros, contras, trampas. ¿Qué tipos de cargas se colocan mejor en un contenedor y cuáles se dejan mejor en un KVM?
LXD o LXC . Es LXD LXC? U otra versión? O un complemento? ¿De qué se trata todo esto? Disipemos los mitos y comprendamos las diferencias entre LXD y LXC.
Aprovisionamiento conveniente . ¿Qué es más conveniente: tomar la misma imagen o instalar el sistema desde cero siempre? ¿Cómo hacerlo de forma rápida y precisa cada vez?
Conveniente máquina virtual. Habrá historias de miedo sobre cargadores de arranque, particiones, LVM.
Varios Muchas preguntas pequeñas: ¿cómo arrastrar rápidamente una máquina virtual de ESXi a KVM, cómo migrar bien, cómo virtualizar discos correctamente?
Motivo de la reubicación
¿De dónde surgió la loca idea de pasar de ESXi a KVM / LXD? ESXi es popular entre las pequeñas y medianas empresas. Este es un hipervisor bueno y barato. Pero hay matices.
Comenzamos con la versión 5.0, convenientemente, ¡todo funciona! La próxima versión 5.5 es la misma.
Desde la versión 6.0 ya es más difícil. En ESXi, la interfaz web no quedó inmediatamente libre, solo a partir de la versión 6.5, antes de que se requiriera una utilidad para Windows. Soportamos esto. Quien ejecuta OS X compra Parallels e instala esta utilidad. Este es un dolor bien conocido.
Monitoreo periódicamente flasheado. Era necesario reiniciar los servicios de administración en la consola del servidor, luego CIM Heartbeat apareció nuevamente. Soportamos, ya que no siempre se cayó.
Versión ESXi 6.5: basura, desperdicios y atrocidades. Horrible hipervisor. Y aquí está el por qué.
- Angular se cae con una excepción en la entrada a la interfaz web. Tan pronto como ingrese su nombre de usuario y contraseña, ¡inmediatamente una excepción!
- La capacidad de controlar de forma remota el estado de la matriz RAID no funciona, ya que es conveniente para nosotros. Solía ser conveniente, pero en la versión 6.5, todo está mal.
- Soporte débil para las tarjetas de red modernas de Intel . Las tarjetas de red de Intel y ESXi causan dolor. Hay un hilo de agonía en el foro de soporte de ESXi sobre esto. VMware e Intel no son amigos y las relaciones no mejorarán en el futuro cercano. Lo triste es que incluso los clientes de soluciones pagas experimentan problemas.
- No hay migración dentro de ESXi . A menos que la migración se considere una pausa, copie y comience el procedimiento. Ponemos el auto en pausa, lo copiamos rápidamente y lo arrancamos en otro lugar. Pero es imposible llamarlo migración, todavía hay uno simple.
Después de ver todo esto, se nos ocurrió la loca idea de movernos con ESXi 6.5.
Lista de deseos
Para empezar, escribimos una lista de deseos para un futuro ideal al que vamos.
Gestión desde debajo de SSH , y web y más opcional. La interfaz web es excelente, pero en un viaje de negocios desde un iPhone, entrar en la interfaz web de ESXi y hacer algo allí es inconveniente y difícil. Por lo tanto, la única forma de administrar todo es SSH, no habrá otra.
Virtualización de Windows. A veces los clientes piden cosas extrañas, y nuestra misión es ayudarlos.
Siempre controladores nuevos y la capacidad de configurar una tarjeta de red . Deseo adecuado, pero no realizado bajo ESXi puro.
Migración en vivo, no agrupamiento . Queremos la capacidad de arrastrar máquinas de un hipervisor a otro sin sentir ningún retraso, tiempo de inactividad o inconvenientes.
La lista de deseos está lista, luego ha comenzado una búsqueda difícil.
Harina de elección
El mercado gira en torno a KVM o LXC con diferentes salsas. A veces parece que Kubernetes está en algún lugar arriba, donde todo está bien, el sol y el paraíso, y en el nivel inferior hay Morlocks: KVM, Xen o algo así ...
Por ejemplo, Proxmox VE es Debian, que fue extraído por el núcleo de Ubuntu. Se ve raro, pero ¿lo trae a producción?
Nuestros vecinos abajo son Alt Linux. Se les ocurrió una solución hermosa: crearon Proxmox VE como un paquete. Simplemente ponen el paquete en un comando. Esto es conveniente, pero no incluimos Alt Linux en producción, por lo que no nos convenía.
Tomar KVM
Al final, elegimos KVM. No lo tomaron, Xen, por ejemplo, debido a la comunidad: KVM tiene mucho más. Parecía que siempre encontraríamos la respuesta a nuestra pregunta. Más tarde descubrimos que el tamaño de una comunidad no afecta su calidad.
Inicialmente, calculamos que tomaríamos una máquina Bare Metal, agregaríamos el Ubuntu con el que estamos trabajando y rodaríamos KVM / LXD desde arriba. Contamos con la capacidad de ejecutar contenedores. Ubuntu es un sistema bien conocido y no hay sorpresas en términos de resolver problemas de arranque / recuperación para nosotros. Sabemos dónde patear si el hipervisor no se inicia. Todo es claro y conveniente para nosotros.
Curso intensivo de KVM
Si eres del mundo de ESXi, encontrarás muchas cosas interesantes. Aprende tres palabras: QEMU, KVM y libvirt.
QEMU traduce los deseos de un SO virtualizado en los desafíos de un proceso regular. Funciona muy bien en casi todas partes, pero lentamente. QEMU es un producto independiente que virtualiza muchos otros dispositivos.
Más adelante en la escena viene un montón de
QEMU-KVM . Este es el módulo del kernel de Linux para QEMU. La virtualización de todas las instrucciones es costosa, por lo que tenemos un módulo de kernel KVM que
traduce solo unas pocas instrucciones . Como resultado, esto es significativamente más rápido, ya que solo se procesa un pequeño porcentaje de las instrucciones del conjunto general. Estos son todos los costos de virtualización.
Si solo tiene QEMU, el inicio de la máquina virtual sin enlace se ve así:
$ qemu < >
En los parámetros que describe la red, bloquee los dispositivos. Todo es maravilloso, pero inconveniente. Por lo tanto hay libvirt.
El objetivo de libvirt es ser una herramienta única para todos los hipervisores . Puede funcionar con cualquier cosa: con KVM, con LXD. Parece que solo queda aprender la sintaxis de libvirt, pero en realidad funciona peor que en teoría.
Estas tres palabras son todo lo que se necesita para generar la primera máquina virtual en KVM. Pero de nuevo, hay matices ...
Libvirt tiene una configuración donde se almacenan máquinas virtuales y otras configuraciones. Almacena la configuración en archivos xml: elegantes, modernos y directamente de los años 90. Si lo desea, se pueden editar a mano, pero por qué, si hay comandos convenientes. También es conveniente que los cambios en los archivos xml estén maravillosamente versionados. Usamos
etckeeper - versión del directorio, etc. Ya es posible usar etckeeper y ya es hora.
Curso intensivo de LXC
Hay muchos conceptos erróneos sobre LXC y LXD.
LXC es la capacidad del núcleo moderno de usar espacios de nombres, para pretender que no es en absoluto el núcleo original.
Puede crear estos espacios de nombres tantos como desee para cada contenedor. Formalmente, el núcleo es uno, pero se comporta como muchos núcleos idénticos. LXC le permite ejecutar contenedores, pero solo proporciona herramientas básicas.
Canonical, que está detrás de Ubuntu y avanza agresivamente los contenedores, ha lanzado
LXD, un análogo de libvirt . Este es un enlace que facilita la ejecución de contenedores, pero en su interior sigue siendo LXC.
LXD es un hipervisor de contenedor basado en LXC.
Enterprise reina en LXD. LXD almacena la configuración en su base de datos, en el directorio
/var/lib/lxd . Allí, LXD lleva su configuración a la configuración en SQlite. Copiarlo no tiene sentido, pero puede escribir los comandos que utilizó para crear la configuración del contenedor.
No hay descarga como tal, pero la mayoría de los cambios son automatizados por equipos. Este es un análogo del archivo Docker, solo con control manual.
Producción
A lo que nos enfrentamos cuando todos navegamos en funcionamiento.
Red
¡Cuánta basura y alboroto infernales en Internet sobre la red en KVM! El 90% de los materiales dicen usar puente.
¡Deja de usar el puente!
¿Qué le pasa a él? Últimamente, tengo la sensación de que la locura está sucediendo con los contenedores: coloque Docker encima de Docker para que pueda ejecutar Docker en Docker mientras mira Docker. La mayoría no entiende lo que está haciendo el puente.
Pone su controlador de red en
modo promiscuo y recibe todo el tráfico porque no sabe cuál y cuál no. Como resultado, todo el tráfico del puente pasa a través de una maravillosa y rápida pila Linux de red, y hay muchas copias. Al final, todo es lento y malo. Por lo tanto, no use bridge en producción.
SR-IOV
SR-IOV es la capacidad de virtualizar dentro de una tarjeta de red . La tarjeta de red en sí misma puede asignar parte de sí misma para máquinas virtuales, lo que requiere cierto soporte de hardware. Esto es lo que evitará la migración. Migrar una máquina virtual donde falta SR-IOV es doloroso.
SR-IOV debe usarse donde todos los hipervisores lo admitan como parte de la migración. Si no, entonces macvtap es para ti.
macvtap
Esto es para aquellos cuya tarjeta de red no es compatible con SR-IOV. Esta es la versión ligera del puente: se cuelgan diferentes direcciones MAC en una tarjeta de red, y
se utiliza el filtrado de unidifusión : la tarjeta de red no acepta todo, pero estrictamente de acuerdo con la lista de direcciones MAC.
Se pueden encontrar más detalles sangrientos en
la gran charla de Toshiaki Makita
, Virtual Switching Technologies y Linux Bridge . Está lleno de dolor y sufrimiento.
El 90% de los materiales sobre cómo construir una red en KVM son inútiles.
Si alguien dice que el puente es increíble, no hables más con esa persona.
Con macvtap, la
CPU ahorra alrededor del 30% debido a menos copias. Pero el modo promiscuo tiene sus propios matices. No puede conectarse a la interfaz de red de la máquina invitada desde el propio hipervisor, desde el host. Un informe de Toshiaki detalla esto. Pero en resumen, no funcionará.
Desde el propio hipervisor rara vez se pasa a SSH. Es más conveniente iniciar una consola allí, por ejemplo, una consola Win. Es posible "ver" el tráfico en la interfaz: no puede conectarse a través de TCP, pero el tráfico en el hipervisor es visible.
Si sus velocidades son superiores a 1 Gigabit, elija macvtap.
A velocidades de interfaz de hasta 1 Gigabit por segundo, el puente también se puede utilizar. Pero si tiene una tarjeta de red de 10 Gb y desea deshacerse de ella de alguna manera, solo queda macvtap. No hay otras opciones. Excepto SR-IOV.
systemd-networkd
Esta es una excelente manera de almacenar la configuración de red en el propio hipervisor . En nuestro caso, esto es Ubuntu, pero para otros sistemas, systemd funciona.
Solíamos tener un archivo
/etc/network/interfaces en el que todos guardamos. Un archivo es incómodo de editar cada vez: systemd-networkd le permite dividir la configuración en una dispersión de archivos pequeños. Esto es conveniente porque funciona con cualquier sistema de versiones: se envió a Git y verá cuándo y qué cambio sucedió.
Hay una falla que descubrieron nuestros networkers. Cuando necesita agregar una nueva VLAN en el hipervisor, voy y configuro. Luego digo: "systemctl restart systemd-networkd". En este momento, todo está bien conmigo, pero si las sesiones de BGP de esta máquina se generan, se rompen. Nuestros networkers no aprueban esto.
Para el hipervisor, no pasa nada malo. Systemd-networkd no es adecuado para usuarios fronterizos, servidores con BGP elevado y para hipervisores: excelente.
Systemd-networkd está lejos de ser final y nunca se completará. Pero esto es más conveniente que editar un archivo enorme. Una alternativa a systemd-networkd en Ubuntu 18.04 es Netplan. Esta es una forma "genial" de configurar la red y pisar el rastrillo.
Dispositivo de red
Después de instalar KVM y LXD en el hipervisor, lo primero que verá son dos puentes. Uno hizo KVM para sí mismo, y el segundo, LXD.
LXD y KVM están intentando desplegar su red.
Si todavía necesita un puente, para máquinas de prueba o para jugar, elimine el puente, que está activado de forma predeterminada y cree el suyo, el que desee. KVM o LXD lo hacen terriblemente: desliza dnsmasq y comienza el horror.
Almacenamiento
No importa qué implementaciones te gusten: usa el almacenamiento compartido.
Por ejemplo, iSCSI para máquinas virtuales. No podrá deshacerse del "punto de falla", pero puede
consolidar el almacenamiento en un punto . Esto abre nuevas oportunidades interesantes.
Para hacer esto, debe tener al menos 10 Gb / s de interfaces dentro del centro de datos. Pero incluso si solo tiene 1 Gbit / s, no se preocupe. Esto es aproximadamente 125 MB / s, bastante bueno para los hipervisores que no requieren una gran carga de disco.
KVM puede migrar y arrastrar el almacenamiento. Pero, por ejemplo, en el modo de carga de trabajo, transferir una máquina virtual a un par de terabytes es una molestia. Para la migración con un almacenamiento común, solo RAM es suficiente, que es elemental. Esto
reduce el tiempo de migración .
Al final, ¿LXD o KVM?
Inicialmente, asumimos que para todas las máquinas virtuales donde el núcleo coincide con el sistema host, tomaremos LXD. Y donde necesitamos tomar otro núcleo: tomar KVM.
En realidad, los planes no despegaron. Para entender por qué, eche un vistazo más de cerca a LXD.
Lxd
La ventaja principal es ahorrar memoria en el núcleo. El núcleo es el mismo y cuando lanzamos nuevos contenedores el núcleo es el mismo. En esto, los pros terminaron y comenzaron los contras.
El dispositivo de bloque con rootfs debe estar montado. Es más difícil de lo que parece.
Realmente no hay migración . Lo es, y se basa en el maravilloso instrumento sombrío que vieron nuestros compatriotas. Estoy orgulloso de ellos, pero en casos simples criu no funciona.
zabbix-agent se comporta de forma extraña en un contenedor . Si lo ejecuta dentro del contenedor, verá una serie de datos del sistema host y no del contenedor. Hasta ahora no se puede hacer nada.
Al mirar la lista de procesos en el hipervisor, es imposible entender rápidamente de qué contenedor está creciendo un proceso en particular . Lleva tiempo descubrir qué espacio de nombres hay, qué y dónde. Si la carga en algún lugar saltó más de lo habitual, rápidamente no lo entiendo. Este es el principal problema: la limitación en las capacidades de respuesta. Se realiza una mini investigación para cada caso.
La única ventaja de LXD es ahorrar memoria central y reducir la sobrecarga.
Pero Kernel Shared Memory en KVM ya ahorra memoria.
Hasta ahora no veo ninguna razón para presentar una producción seria y LXD. A pesar de los mejores esfuerzos de Canonical en esta área, la producción de LXD trae más problemas que soluciones. En un futuro cercano, la situación no cambiará.
Pero, no se puede decir que LXD es malo. Es bueno, pero en casos limitados, de lo que hablaré más adelante.
Criu
Criu es una utilidad sombría.
Cree un contenedor vacío, llegará con un cliente DHCP y le dirá: "¡Suspenda!" Obtenga el error porque hay un cliente DHCP: “¡Horror, horror! Abre el zócalo con el letrero "crudo", ¡qué pesadilla! " Peor en ninguna parte.
Impresiones de contenedores: sin migración, Criu funciona en cualquier otro momento.
Me gusta la recomendación del equipo de LXD sobre qué hacer con Criu para que no haya problemas:
- ¡
Toma una versión más fresca del repositorio!¿Y de alguna manera puedo ponerlo desde el paquete para que no se ejecute en el repositorio?
Conclusiones
LXD es maravilloso si desea crear una infraestructura de CI / CD. Tomamos LVM - Logical Volume Manager, tomamos una instantánea de él e iniciamos el contenedor en él. ¡Todo funciona muy bien! En un segundo, se crea un nuevo contenedor limpio, que está configurado para probar y hacer rodar al chef; lo usamos activamente.
LXD es débil para una producción seria . No podemos saber qué hacer con LXD en producción si no funciona bien.
¡Elija KVM y solo KVM!La migracion
Diré esto brevemente. Para nosotros, la migración resultó ser un maravilloso mundo nuevo que nos gusta. Allí todo es simple: hay un equipo para la migración y dos opciones importantes:
virsh migrate <vm> qemu+ssh://<hypervisor>/system --undefinesource -persistent
Si escribe "Migración KVM" en Google y abre el primer material, verá un comando para la migración, pero sin las dos últimas teclas. No verá una mención de que son importantes: "¡Simplemente ejecute este comando!" Ejecute el comando, y realmente migra, pero ¿cómo?
Importantes opciones de migración.
undefinesource: elimina la máquina virtual del hipervisor desde el que estamos migrando. Si reinicia después de dicha migración, el hipervisor que dejó reiniciará esta máquina. Te sorprenderás, pero esto es normal.
Sin el segundo parámetro, persistente, el hipervisor al que se mudó no considera en absoluto que se trate de una migración permanente. Después de reiniciar, el hipervisor no recordará nada.
- virsh dominfo <vm> | grep persistent
Sin este parámetro, la máquina virtual es círculos en el agua. Si el primer parámetro se especifica sin el segundo, adivine qué sucederá.
Hay muchos de esos momentos con KVM.
- Red: siempre te hablan sobre bridge, ¡es una pesadilla! Usted lee y piensa: ¿cómo es eso?
- Migración: tampoco dirán nada inteligible, hasta que te golpees la cabeza contra esta pared.
Por donde empezar
Para empezar tarde, estoy hablando de otra cosa.
Aprovisionamiento: cómo implementarlo
Si está satisfecho con las opciones de instalación estándar, el mecanismo predeterminado es excelente.
Bajo ESXi, usamos virt-install. Esta es una forma habitual de implementar una máquina virtual. Es conveniente que cree un archivo preestablecido en el que describa la imagen de su Debian / Ubuntu. Inicie una nueva máquina alimentándola con un kit de distribución ISO y un archivo preestablecido. Entonces el auto rueda solo. Te conectas a través de SSH, lo conectas a un chef, enrollas galletas, ¡eso es todo, apúrate a la producción!
Pero si tienes suficiente virt-install, tengo malas noticias. Esto significa que no ha llegado a la etapa en que desea hacer otra cosa. Lo superamos y nos dimos cuenta de que virt-install no es suficiente. Llegamos a una "imagen dorada", que clonamos y luego lanzamos máquinas virtuales.
¿Y cómo organizar una máquina virtual?
¿Por qué llegamos a esta imagen y por qué es importante el aprovisionamiento? Debido a que todavía hay una comprensión débil en la comunidad de que hay grandes diferencias entre una máquina virtual y una máquina normal.
Una máquina virtual no necesita un proceso de arranque complicado y un cargador de arranque inteligente . Es mucho más fácil conectar los discos de una máquina virtual a una máquina que tiene un conjunto completo de herramientas que en modo de recuperación tratando de salir a alguna parte.
Una máquina virtual necesita la simplicidad de un dispositivo . ¿Por qué necesito particiones en un disco virtual? ¿Por qué la gente toma un disco virtual y coloca particiones allí, no LVM?
Una máquina virtual necesita la máxima extensibilidad . Por lo general, las máquinas virtuales crecen. Este es un proceso "genial": aumentar la partición en el MBR. Lo borra, en ese momento se limpia el sudor de la frente y piensa: "¡Simplemente no escriba ahora, simplemente no escriba!" - Y recrear con los nuevos parámetros.
LVM @ lilo
Como resultado, llegamos a LVM @ lilo. Este es un gestor de arranque que le permite configurar desde un solo archivo. Si para editar la configuración de GRUB está editando un archivo especial que controla el motor de plantillas y crea el monstruoso boot.cfg, luego con Lilo, un archivo y nada más.
Partitionless LVM hace que el sistema sea perfecto y fácil. El problema es que GRUB no puede vivir sin MBR o GPT y se está congelando. Le decimos: "GRUB establecete aquí", pero no puede, porque no hay particiones.
LVM le permite expandirse rápidamente y hacer copias de seguridad. Diálogo estándar:
- Chicos, ¿cómo hacen copias de seguridad virtuales?- ... tomamos un dispositivo de bloque y copiamos.- ¿Has intentado desplegar de nuevo?- Bueno, no, ¡todo funciona para nosotros!Puede lamer un dispositivo de bloque en una máquina virtual en cualquier momento, pero si hay un sistema de archivos, cualquier registro requiere tres movimientos; este procedimiento no es atómico.
Si está haciendo una instantánea de la máquina virtual desde el interior, puede comunicarse con el sistema de archivos para que llegue al estado coherente deseado. Pero esto no es adecuado para todo.
¿Cómo construir un contenedor?
Para comenzar y crear un contenedor, hay herramientas regulares de las plantillas. LXD ofrece la plantilla Ubuntu 16.04 o 18.04. Pero si eres un luchador avanzado y no quieres una plantilla regular, pero tus rootfs personalizados, que puedes personalizar para ti, surge la pregunta: ¿cómo crear un contenedor desde cero en LXD?
Contenedor desde cero
Preparando rootfs . Debootstrap ayudará con esto: explicamos qué paquetes son necesarios, cuáles no y los instalamos.
Explique a LXD que queremos crear un contenedor a partir de rootfs específicos . Pero primero, cree un contenedor vacío con un comando breve:
curl --unix-socket /var/lib/lxd/unix.socket -X POST -d '{"name": "my-container", "source": {"type": "none"}}' lxd/1.0/containers
Incluso puede ser automatizado.
Un lector atento dirá: ¿dónde está rootfs my-container? ¿Dónde se indica en qué lugar? ¡Pero no dije que eso es todo!
Montamos rootfs del contenedor donde vivirá. Luego indicamos que el contenedor rootfs vivirá aquí:
lxc config set my-container raw.lxc "lxc.rootfs=/containers/my-container/rootfs"
De nuevo, esto está automatizado.
Vida del contenedor
El contenedor no tiene su propio núcleo , por lo que cargarlo es más fácil
: systemd, init, y voló.
Si no utiliza herramientas regulares para trabajar con LVM, entonces, en la mayoría de los casos, para iniciar el contenedor, deberá montar el rootfs del contenedor en el hipervisor.
A veces encuentro artículos que aconsejan autofs. No lo hagas. Systemd tiene unidades de montaje automático que funcionan, pero autofs no. Por lo tanto, las unidades systemd automount pueden y deben usarse, pero autofs no vale la pena.
Conclusiones
Nos gusta KVM con migración . Con LXD, todavía no es el camino, aunque para probar y construir la infraestructura la usamos donde no hay carga de producción.
Nos encanta el rendimiento de KVM . Es más familiar mirar hacia arriba, ver allí un proceso que sea relevante para esta máquina virtual y comprender quién y qué estamos haciendo. Esto es mejor que usar un conjunto de utilidades extrañas con contenedores para descubrir qué tipo de golpes bajo el agua hay.
Estamos encantados con la migración. Esto se debe en gran parte al almacenamiento compartido. Si migramos arrastrando discos, no seríamos tan felices.
Si usted, como Leo, está listo para hablar sobre la superación de las dificultades de operación, integración o soporte, entonces es el momento de enviar un informe a la conferencia DevOpsConf de otoño. Y nosotros en el comité del programa ayudaremos a preparar la misma presentación inspiradora y útil que esta.
No estamos esperando la fecha límite para la convocatoria de ponencias y ya hemos aceptado varios informes para el programa de la conferencia. Suscríbase al boletín y al canal de telegramas y manténgase actualizado sobre las noticias sobre los preparativos para DevOpsConf 2019 y no se pierda nuevos artículos y videos.