Plataformas como Kubernetes, Nomad o cualquier plataforma como servicio (Paas) alojada en la nube ofrecen una variedad de capacidades poderosas. Desde el escalado de cargas de trabajo hasta la gestión de secretos y las estrategias de implementación, estos orquestadores de cargas de trabajo están optimizados para ayudar a escalar la infraestructura de diferentes maneras. Pero, ¿los operadores siempre deben pagar el costo de la máxima escalabilidad? A veces, el costo de la complejidad y la abstracción superan sus beneficios. En cambio, muchos constructores llegan a confiar en arquitecturas de implementación radicalmente simples para facilitar la administración. Dos servidores privados virtuales detrás de un equilibrador de carga son una pila drásticamente más sencilla de administrar en comparación con un grupo de microservidores en expansión en una flota de hosts de contenedores. Esto puede empezar a dar sus frutos cuando hay menos piezas móviles que depurar cuando surgen problemas o actualizar cuando llega el momento de darles mantenimiento. La base de muchas distribuciones modernas de Linux es y viene con un sólido conjunto de características que a menudo son comparables a los orquestadores de contenedores o sistemas PaaS. En este artículo, exploraremos cómo puede aprovechar las últimas características de systemd para obtener muchas de las capacidades de esos otros sistemas grandes sin el dolor de cabeza de administración y potenciar cualquier servidor común para que sea una plataforma de aplicaciones muy capaz. systemd Linux Una introducción a systemd En un solo host, escribir un archivo systemd es una forma ideal de ejecutar un proceso administrado. La mayoría de las veces, ni siquiera es necesario cambiar la aplicación: systemd admite una variedad de diferentes tipos de servicios y puede adaptarse en consecuencia. .service Por ejemplo, considere este simple que define cómo ejecutar un servicio web simple: .service [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080 Recuerde los valores predeterminados para los servicios systemd: debe ser una ruta absoluta, los procesos no deben bifurcarse en segundo plano y es posible que deba configurar las variables de entorno necesarias con la opción . ExecStart= Environment= Cuando se coloca en un archivo como , crea un servicio que puedes controlar con : /etc/systemd/system/webapp.service systemctl iniciará el proceso. systemctl start webapp mostrará si el servicio se está ejecutando, su tiempo de actividad y el resultado de y , así como el ID del proceso y otra información. systemctl status webapp stderr stdout finalizará el servicio. systemctl stop webapp Además, todos los resultados impresos en y se agregarán mediante diario y se podrá acceder a ellos a través del diario del sistema (con ) o se dirigirán específicamente mediante el indicador : stderr stdout journalctl --unit journalctl --unit webapp Debido a que el diario rota y administra su almacenamiento de forma predeterminada, recopilar registros a través del diario es una buena estrategia para administrar el almacenamiento de registros. El resto de este artículo explorará opciones para mejorar un servicio como este. Misterios admiten la capacidad de inyectar de forma segura: valores extraídos de almacenes de datos seguros y expuestos a cargas de trabajo en ejecución. Los datos confidenciales, como claves API o contraseñas, requieren un tratamiento diferente al de las variables de entorno o archivos de configuración para evitar una exposición involuntaria. Los orquestadores de contenedores como Kubernetes secretos La systemd admite la carga de valores confidenciales de archivos en el disco y exponerlos a servicios en ejecución de forma segura. Al igual que las plataformas alojadas que administran secretos de forma remota, systemd tratará de manera diferente a los valores como las variables de entorno para garantizar que se mantengan seguras. opción LoadCredential= las Credenciales Para inyectar un secreto en un servicio systemd, comience colocando un archivo que contenga el valor secreto en una ruta del sistema de archivos. Por ejemplo, para exponer una clave API a una unidad , cree un archivo en para conservar el archivo después de los reinicios o en para evitar que el archivo persista permanentemente (el La ruta puede ser arbitraria, pero systemd tratará estas rutas como predeterminadas). En cualquier caso, el archivo debería tener permisos restringidos mediante un comando como . .service /etc/credstore/api-key /run/credstore/api-key credstore chmod 400 /etc/credstore/api-key En la sección del archivo , defina la opción y pásele dos valores separados por dos puntos ( ): el nombre de la credencial y su ruta. Por ejemplo, para llamar “token” a nuestro archivo , defina la siguiente opción de servicio systemd: [Service] .service LoadCredential= : /etc/credstore/api-key LoadCredential=token:/etc/credstore/api-key Cuando systemd inicia su servicio, el secreto se expone al servicio en ejecución bajo una ruta del formato donde es una variable de entorno completada por systemd. El código de su aplicación debe leer cada secreto definido de esta manera para su uso en bibliotecas o códigos que requieren valores seguros como tokens API o contraseñas. Por ejemplo, en Python, puedes leer este secreto con un código como el siguiente: ${CREDENTIALS_DIRECTORY}/token ${CREDENTIALS_DIRECTORY} from os import environ from pathlib import Path credentials_dir = Path(environ["CREDENTIALS_DIRECTORY"]) with Path(credentials_dir / "token").open() as f: secret = f.read().strip() Luego puede usar la variable con el contenido de su secreto para cualquier biblioteca que pueda requerir un token API o una contraseña. secret Se reinicia Otra capacidad de los orquestadores como es la capacidad de automáticamente una carga de trabajo que ha fallado. Ya sea debido a un error de aplicación no controlado o alguna otra causa, reiniciar aplicaciones fallidas es una capacidad muy útil que suele ser la primera línea de defensa al diseñar una aplicación para que sea resistente. Nomad reiniciar La systemd controla si systemd reiniciará automáticamente un proceso en ejecución. Hay varios valores potenciales para esta opción, pero para los servicios básicos, la configuración es adecuada para satisfacer la mayoría de los casos de uso. opción Restart= on-failure Otra configuración a considerar al configurar el reinicio automático es , que dicta cuánto tiempo esperará systemd antes de iniciar el servicio nuevamente. Normalmente, este valor debe personalizarse para evitar reiniciar servicios fallidos en un bucle cerrado y consumir demasiado tiempo de CPU dedicado a reiniciar procesos. Un valor corto que no espere , como , suele ser suficiente. la opción RestartSec= demasiado 5s Opciones como que aceptan períodos de duración o valores basados en el tiempo pueden analizar una variedad de formatos como o según sus necesidades. Consulte para obtener información adicional. RestartSec= 5min 10s 1hour el manual de systemd.time Finalmente, otras dos opciones dictan la agresividad con la que systemd intentará reiniciar las unidades fallidas antes de darse por vencido. y controlarán la frecuencia con la que se permite que una unidad arranque dentro de un período de tiempo determinado. Por ejemplo, las siguientes configuraciones: StartLimitIntervalSec= StartLimitBurst= StartLimitBurst=5 StartLimitIntervalSec=10 Solo permitirá que una unidad intente arrancar un máximo de 5 veces durante un período de 10 segundos. Si el servicio configurado intenta iniciarse por sexta vez en un período de 10 segundos, systemd dejará de intentar reiniciar la unidad y la marcará como . failed Combinando todas estas configuraciones, puede incluir las siguientes opciones para que su unidad configure reinicios automáticos: .service [Unit] StartLimitBurst=5 StartLimitIntervalSec=10 [Service] Restart=on-failure RestartSec=1 Esta configuración reiniciará un servicio si falla (es decir, se cierra inesperadamente, como con un código de salida distinto de cero) después de esperar un segundo y dejará de intentar reiniciar el servicio si intenta iniciarlo más de cinco veces en el transcurso. de 10 segundos. Endurecimiento del servicio Uno de los principales beneficios de ejecutar dentro de un contenedor es la zona de pruebas de seguridad. Al segmentar un proceso de aplicación del sistema operativo subyacente, es mucho más difícil que cualquier vulnerabilidad que pueda estar presente en el servicio se convierta en un compromiso total. Los tiempos de ejecución como Docker logran esto mediante una combinación de cgroups y otras primitivas de seguridad. Puede habilitar varias opciones de systemd para imponer restricciones similares que pueden ayudar a proteger un host subyacente contra comportamientos impredecibles de la carga de trabajo: puede restringir el acceso de escritura a rutas sensibles del sistema como y . enumera todas las opciones disponibles, pero en términos generales, establecer esta opción en es un valor predeterminado razonable para proteger estas rutas del sistema de archivos. ProtectSystem= /boot /usr La documentación para esta opción full puede configurar los directorios , y en solo lectura con la configuración o, cuando se establece en , montarlos en el sistema de archivos del servicio como directorios vacíos. A menos que su aplicación tenga una necesidad específica de acceder a estos directorios, establecer esto en puede proteger de forma segura el sistema contra el acceso ilegítimo a esos directorios. ProtectHome= /home /root /run/user read-only true true mantiene un y separados para el servicio configurado, de modo que los archivos temporales para este servicio y otros procesos permanezcan privados. A menos que exista una razón convincente para que los procesos compartan información a través de archivos temporales, esta es una opción útil para habilitar. PrivateTmp= /tmp /var/tmp de reforzar un servicio garantizando que el proceso ejecutado no pueda elevar sus privilegios. Si no está seguro de poder utilizar otras opciones de refuerzo, esta suele ser una de las menos problemáticas de habilitar. NoNewPrivileges= es otra forma segura y sencilla es un recurso útil para explorar las diferentes opciones que se aplican a cargas de trabajo ejecutables como servicios. La página del manual de systemd.exec Otras lecturas Las son extensas y útiles para conocer todas las opciones disponibles para ejecutar sus propias aplicaciones. Ya sea que esté ejecutando un servicio persistente como un servidor web o una unidad periódica para reemplazar un trabajo cron, la documentación de systemd puede ofrecerle una guía útil. páginas del manual del proyecto systemd .timer

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Este audio es producido en el idioma original de la historia!

Micro-DevOps con Systemd: potencia cualquier servidor Linux común

Demasiado Largo; Para Leer

@tylerjl

Credibility

HISTORIAS RELACIONADAS