Guía del administrador del sistema para aplicaciones en contenedores

Durante años, me he tambaleado al mover mi propio blog, sistema de tickets y wiki a contenedores. Literalmente, el ticket ha estado abierto en Request Tracker desde el 11 de marzo de 2017. Es vergonzoso admitirlo, dado lo involucrado que estoy con los contenedores en Red Hat.

Desde los primeros días de Docker en Red Hat Enterprise Linux 7 (alrededor de 2014), durante la construcción OpenShift 3 en Kubernetes en lugar de Gears; a partir de lanzamiento de CRI-O como avance tecnológico en OpenShift 3.7 el lanzamiento del módulo Container Tools con Podman, Buildah, Skopeo en RHEL 8; desde la adquisición de CoreOS, incluido Quay.io (uno de mis servicios favoritos), hasta el lanzamiento de Red Hat Universal Base Image; He utilizado, probado e incluso impulsado la hoja de ruta de la tecnología de contenedores de forma exhaustiva en Red Hat. Aún así, me tomó hasta 2020 completar el boleto # 627.

Por supuesto, construí toneladas de demostraciones, realicé toneladas de experimentos y pensé durante horas y horas en cómo migrar cosas. He tenido cientos o miles de conversaciones sobre migración con clientes y miembros de la comunidad, pero no he encontrado el tiempo para convertir mis servicios personales de Linux. Así que no se sienta mal si todavía mira con anhelo desde lejos los elegantes servicios en contenedores de otras personas, ya que recientemente superé el bache.

Finalmente lo hice y quiero compartir mi solución técnica y desglosar mis decisiones de diseño conscientes. Espero que esto te ayude a mover tus propios servicios a contenedores. El objetivo es darte un asesoramiento sólido, conciso y técnico. Aquí están los tres servicios que veremos de cerca en este artículo:

UN SERVICIOOBJETIVOLA TECNOLOGIA
WordPressBlogApache, PHP, Administrador de procesos FastCGI (FPM), MariaDB, WordPress
MediaWikiwikiApache, PHP, Administrador de procesos FastCGI (FPM), MariaDB, Cron, MediaWiki
Seguimiento de solicitudesSistema de venta de entradasApache, FastCGI, Perl, MariaDB, Postfix, Cron, seguimiento de solicitudes

Estos son servicios de Linux muy comunes y parecen tan simples a primera vista. Pero la verdad es que realmente no lo son. Necesita conocimientos avanzados de Linux para contenerlos bien. Estos son solo ejemplos, pero una inspección minuciosa de estos servicios en contenedores debería proporcionar una base para su propio trabajo.

Índice

    Metodología

    Si busca con Google, encontrará páginas y páginas de blogs, libros blancos y artículos. Un vistazo rápido a cinco o diez de los resultados lo llevará a las mismas tres opciones principales:

    Para ser claros, estas son las mismas tres opciones que la gente ha tenido durante muchos años. Por cierto, antes de los mainframes no había portabilidad. Tuviste que reescribir tu aplicación desde cero para cada ordenador diferente (Breve historia de la portabilidad de código). Desde la llegada de los sistemas operativos y lenguajes de programación estandarizados, ha existido alguna permutación de las mismas tres opciones. He aquí algunos ejemplos:

    • Mainframe a Unix - sobre todo reescribir
    • De Unix a Linux: levante y mueva, refactorice, reescriba
    • Bare metal a máquinas virtuales - principalmente lift and shift
    • Máquinas virtuales a la nube: principalmente refactorización, reescritura
    • De Windows a Linux: levante y mueva, refactorice, reescriba
    • Desde procesos de Linux hasta procesos de Linux en contenedores: levante y mueva, refactorice, reescriba

    De hecho, si buscas, el segundo artículo que encontrarás es el que escribí, profundizando en estas tres opciones y algunas técnicas sobre cómo analizar la arquitectura, la seguridad y el rendimiento: (Buenas prácticas para la migración a aplicaciones en contenedores - 11 páginas). Además, aquí hay una presentación que hice sobre el mismo tema: Contenedores para adultos "Migración de aplicaciones tradicionales y existentes: Video y Diapositivas.

    En aras de la simplicidad, cubriré brevemente las partes más esenciales del informe técnico y la presentación anterior. La gran mayoría del software que usamos hoy en día fue diseñado y escrito antes de los contenedores de Linux, por lo que incluso cuando está escribiendo (o reescribiendo) software desde cero, necesita las mismas habilidades. Estas habilidades serán algo natural para los administradores y arquitectos de sistemas Linux. Ahora, echemos un vistazo a lo que hice específicamente para mis propios servicios.

    Para mis blogs, wiki y sistema de tickets, la reescritura y la refactorización estaban totalmente fuera de discusión. Ahora quizás se pregunte por qué no simplemente cambiar a Jira para la emisión de boletos, wordpress.com para sus blogs y un servicio gratuito para su wiki. Bueno, no puedo mudarme por las mismas razones por las que la mayoría de las grandes empresas no pueden mudarse. Hay demasiados datos integrados en mis servicios, desde aprender Jiu-Jitsu y proyectos personales hasta cambiar el diferencial en mi Crossfire SRT 6 de 2005. Todo lo que he hecho en los últimos 10 años está integrado con estos servicios de Linux. Son básicamente una extensión de mi cerebro. Hay casi 1000 tickets en Request Tracker, 800 páginas en mi wiki y más de 200 artículos en mis dos blogs. De hecho, al igual que una gran corporación, elegí deliberadamente MediaWiki porque sé que existirá mientras exista Wikipedia y que probablemente me sobreviva. Literalmente estoy planeando escribir mi última entrada de MediaWiki unos días antes del inicio, así que solo necesito que MediaWiki esté disponible por otros 20 o 30 años. Teniendo en cuenta las necesidades de mi negocio, elegí, con un poco de refactorización mezclada.

    Ahora pasemos al nivel de esfuerzo. Aquí hay algunas pautas sobre lo difícil que es mover diferentes servicios:

    FÁCILMODERARDIFÍCIL
    codificadoCompletamente aislado (proceso único)Algo aislado (varios procesosAuto-modificación (por ejemplo, modelo de actor)
    ConfiguraciónUn archivoMúltiples archivosEn cualquier parte del sistema de archivos
    DatosGuardado en un solo lugarMúltiples archivos en múltiples ubicacionesEn cualquier parte del sistema de archivos
    Misteriosarchivos estáticosRedGeneración de certificados dinámicos
    RedHTTP, HTTPSTCP, UDPIPSEC, altamente aislado
    InstalaciónPaquetes, FuenteInstalador y configuración incluidosInstaladores (install.sh)
    LicenciaFuente abiertaDueñoRestrictivo y propietario
    RecuperabilidadFácil de reiniciarfallar a vecesA menudo falla

    Una vez que haya decidido entre levantar y cambiar, refactorizar o reescribir, debe evaluar el nivel de esfuerzo, ya que incluso las aplicaciones más nuevas (incluidos los microservicios) se basan en lenguajes de programación y demonios de Linux escritos antes de que existieran los contenedores. Afortunadamente, la mayoría de los servicios de Unix y Linux están diseñados de forma modular, lo que los hace propicios para la separación de código, configuración y datos. Es una necesidad absoluta cuando se mueve software en contenedores. Además, debe pensar en la instalación (y las actualizaciones en el caso de WordPress), los secretos y la capacidad de recuperación. Para profundizar más en la tabla anterior, consulte: Arquitectura de contenedores Parte 4: Características de la carga de trabajo y candidatos para la contenedorización

    Separar los servicios en código, configuración y datos requiere un sólido conjunto de habilidades de Linux. Con unas pocas horas de inversión en el aprendizaje de conceptos clave de contenedores, un administrador o arquitecto de sistemas Linux sólido puede comenzar de manera productiva a mover servicios en contenedores. Para profundizar en las habilidades que un administrador de Linux necesita para aprender contenedores de Linux, consulte: Taller: Componentes internos del contenedor Linux 2.0.

    En nuestro próximo artículo, profundizaremos en WordPress y el pasos para mover su blog de WordPress existente a un contenedor.

    Artículos de interés

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada.

    Subir