book

Infraestructura como código, 2ª edición

by Kief Morris

September 2024

Intermediate to advanced

430 pages

12h 33m

Spanish

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Por qué escribí este libroNovedades y diferencias de esta edición¿Qué sigue?Qué es y qué no es este libroAlgo de historia de la infraestructura como códigoA quién va dirigido este libroPrincipios, prácticas y modelosEjemplos de ShopSpinnerConvenciones utilizadas en este libroAprendizaje en línea O'ReillyCómo contactar con nosotrosAgradecimientos
De la Edad de Hierro a la Edad de las NubesInfraestructura como códigoVentajas de la Infraestructura como CódigoUtiliza la infraestructura como código para optimizar el cambioObjeción: "No hacemos cambios con la frecuencia suficiente para justificar su automatización"Objeción: "Debemos construir primero y automatizar después"Objeción: "Debemos elegir entre rapidez y calidad"Las cuatro métricas claveTres prácticas básicas para la Infraestructura como CódigoPráctica básica: Define todo como códigoPráctica básica: Probar y entregar continuamente todo el trabajo en cursoPráctica Básica: Construye Piezas Pequeñas y Sencillas Que Puedas Cambiar IndependientementeConclusión
Principio: Suponer que los sistemas no son fiablesPrincipio: Haz que todo sea reproducibleError: Sistemas de copos de nievePrincipio: Crear cosas desechablesPrincipio: Minimizar la variaciónDeriva de configuraciónPrincipio: Asegúrate de que puedes repetir cualquier procesoConclusión
Las partes de un sistema de infraestructurasPlataformas de infraestructuraRecursos de infraestructuraRecursos informáticosRecursos de almacenamientoRecursos de redConclusión
Por qué debes definir tu infraestructura como códigoLo que puedes definir como códigoElegir Herramientas con Configuración ExternalizadaGestiona tu código en un sistema de control de versionesLenguajes de codificación de infraestructurasGuiones de InfraestructuraLenguajes declarativos de infraestructuraLenguajes de infraestructura programables e imperativosLenguajes declarativos frente a imperativos para infraestructurasLenguajes de infraestructura específicos de dominioLenguajes de propósito general frente a DSL para infraestructurasPrincipios de aplicación para definir la infraestructura como códigoSeparar código declarativo e imperativoTrata el código de infraestructura como código realConclusión
¿Qué es una pila de infraestructuras?Código de pilaInstancia de la pilaConfigurar servidores en una pilaLenguajes de infraestructura de bajo nivelLenguajes de infraestructura de alto nivelPatrones y antipatrones para estructurar pilasAntipatrón: Pila monolíticaPatrón: Pila de grupos de aplicacionesPatrón: Pila de serviciosPatrón: Micro StackConclusión
De qué tratan los entornosEntornos de entregaMúltiples entornos de producciónEntornos, coherencia y configuraciónPatrones para construir entornosAntipatrón: Pila de varios entornosAntipatrón: Entornos de copiar y pegarPatrón: Pila reutilizableConstruir entornos con múltiples pilasConclusión
Utilizar parámetros de pila para crear identificadores únicosEjemplo de parámetros de pilaPatrones para configurar pilasAntipatrón: Parámetros manuales de la pilaPatrón: Variables de entorno de pilaPatrón: Parámetros con guiónPatrón: Archivos de configuración de la pilaPatrón: Pila envolventePatrón: Parámetros de la pila de tuberíasPatrón: Registro de parámetros de pilaRegistro de configuraciónImplementar un Registro de ConfiguraciónRegistros de configuración únicos o múltiplesManejo de secretos como parámetrosCifrar secretosAutorización secretaInyectar secretos en tiempo de ejecuciónSecretos desechablesConclusión

¿Por qué probar continuamente el código de la infraestructura?Qué significan las pruebas continuas¿Qué debemos probar con la infraestructura?Desafíos de probar el código de la infraestructuraReto: Las pruebas para el código declarativo suelen tener poco valorReto: Probar el código de la infraestructura es lentoDesafío: Las dependencias complican la infraestructura de pruebasPruebas progresivasPirámide de pruebasModelo de prueba del queso suizoConductos de suministro de infraestructurasEtapas de la tuberíaAlcance de los componentes probados en una etapaAlcance de las relaciones utilizadas para una etapaElementos de la plataforma necesarios para un escenarioSoftware y servicios de canalización de entregasPruebas en producciónLo que no puedes reproducir fuera de la producciónGestionar los riesgos de las pruebas en producciónConclusión
Ejemplo de infraestructuraLa pila de ejemploCanalización de la pila de ejemploEtapas de prueba offline para pilasComprobación sintácticaAnálisis estático de código fuera de líneaAnálisis estático de código con APIPruebas con una API simuladaEtapas de la prueba en línea para pilasAvance: Ver qué cambios se introduciránVerificación: Hacer afirmaciones sobre los recursos de infraestructuraResultados: Probar que la infraestructura funciona correctamenteUtilizar dispositivos de prueba para gestionar las dependenciasDobles de prueba para dependencias ascendentesDispositivos de prueba para dependencias descendentesRefactoriza los componentes para que puedan aislarsePatrones del ciclo de vida de las instancias de prueba de las pilasPatrón: Pila de pruebas persistentePatrón: Pila de pruebas efímeraAntipatrón: Doble Etapa de Pila Persistente y EfímeraPatrón: Reconstrucción periódica de la pilaPatrón: Reinicio continuo de la pilaOrquestación de pruebasApoya las pruebas localesEvita el Acoplamiento Estrecho con Herramientas para TuberíasHerramientas de orquestación de pruebasConclusión
Infraestructura nativa de la nube y orientada a las aplicacionesObjetivos del tiempo de ejecución de la aplicaciónPartes implementables de una aplicaciónPaquetes de ImplementaciónImplementación de aplicaciones en servidoresAplicaciones de envasado en recipientesImplementación de aplicaciones en clusters de servidoresImplementación de aplicaciones en clusters de aplicacionesPaquetes para la Implementación de Aplicaciones en ClustersImplementación de aplicaciones sin servidor FaaSDatos de aplicaciónEsquemas y estructuras de datosInfraestructura de almacenamiento de aplicaciones nativas de la nubeConectividad de aplicacionesDescubrimiento de serviciosConclusión
Qué hay en un servidorDe dónde vienen las cosasCódigo de configuración del servidorMódulos de código de configuración del servidorDiseño de módulos de código de configuración del servidorVersionar y promover el código del servidorFunciones del servidorProbar el código del servidorProbar progresivamente el código del servidorQué probar con el código del servidorCómo probar el código del servidorCrear una nueva instancia de servidorCreación manual de una nueva instancia de servidorUtilizar un script para crear un servidorUtilizar una herramienta de gestión de pilas para crear un servidorConfigurar la Plataforma para Crear Servidores AutomáticamenteUtilizar una herramienta de aprovisionamiento en red para crear un servidorServidores de PreconstrucciónClonar en caliente un servidorUtilizar una instantánea del servidorCrear una imagen limpia del servidorConfigurar una nueva instancia de servidorFreír una instancia de servidorImágenes del servidor de cocciónCombinar hornear y freírAplicar la configuración del servidor al crear un servidorConclusión
Patrones de gestión de cambios: Cuándo aplicar los cambiosAntipatrón: Aplicar al cambiarPatrón: Sincronización continua de la configuraciónPatrón: Servidor inmutableCómo aplicar el código de configuración del servidorPatrón: Configuración del Servidor PushPatrón: Configuración del servidor pullOtros eventos del ciclo de vida del servidorDetener y reiniciar una instancia del servidorSustituir una instancia de servidorRecuperar un servidor averiadoConclusión
Crear una imagen de servidor¿Por qué crear una imagen de servidor?Cómo crear una imagen de servidorHerramientas para crear imágenes de servidorProceso de creación de imagen en líneaProceso de creación de imágenes offlineContenido de origen para una imagen de servidorConstruir a partir de una imagen de servidor de stockCrear una imagen de servidor desde ceroProcedencia de una imagen de servidor y su contenidoCambiar una imagen de servidorRecalentar u hornear una imagen frescaVersionar una imagen de servidorActualizar las instancias del servidor cuando cambia una imagenProporcionar y utilizar una imagen de servidor en todos los equiposManejar cambios importantes en una imagenUtilizar una canalización para probar y entregar una imagen de servidorEtapa de construcción de una imagen de servidorEtapa de prueba de una imagen de servidorEtapas de entrega de una imagen de servidorUtilizar varias imágenes de servidorImágenes de servidor para diferentes plataformas de infraestructuraImágenes de servidor para distintos sistemas operativosImágenes de servidor para diferentes arquitecturas de hardwareImágenes de servidor para distintos rolesEstratificación de imágenes de servidorCompartir código entre imágenes de servidorConclusión
Soluciones de clúster de aplicacionesClúster como servicioDistribución de clústeres empaquetadosTopologías de pila para clusters de aplicacionesPila monolítica mediante clúster como servicioPila monolítica para una solución de clúster empaquetadaPipeline para una pila de clústeres de aplicaciones monolíticasEjemplo de varias pilas para un clústerEstrategias de compartición para clusters de aplicacionesUn gran clúster para todoAgrupaciones separadas para etapas de entregaClusters para la GobernanzaAgrupaciones para equiposMalla de servicioInfraestructura para FaaS sin servidorConclusión
Diseñar para la modularidadCaracterísticas de los componentes bien diseñadosReglas para el diseño de componentesUtiliza las pruebas para tomar decisiones de diseñoModularizar la infraestructuraComponentes de pila frente a pilas como componentesUtilizar un servidor en una pilaTrazar límites entre componentesAlinear los límites con los patrones de cambio naturalesAlinea los límites con los ciclos de vida de los componentesAlinear los límites con las estructuras organizativasCrea límites que favorezcan la resilienciaCrea límites que apoyen la ampliaciónAlinear los límites con las preocupaciones de seguridad y gobernanzaConclusión
Lenguajes de infraestructura para los componentes de la pilaReutiliza el código declarativo con módulosCrear dinámicamente elementos de pila con bibliotecasPatrones para componentes de pilaPatrón: Módulo FachadaAntipatrón: Módulo de ofuscaciónAntipatrón: Módulo no compartidoPatrón: Módulo BundleAntipatrón: Módulo EspaguetiPatrón: Entidad de dominio de la infraestructuraConstruir una capa de abstracciónConclusión
Descubrir dependencias entre pilasPatrón: Coincidencia de recursosPatrón: Búsqueda de datos en la pilaPatrón: Búsqueda en el Registro de IntegraciónInyección de dependenciaConclusión
Organizar proyectos y repositorios¿Un repositorio o muchos?Un repositorio para todoUn repositorio separado para cada proyecto (Microrepo)Múltiples repositorios con múltiples proyectosOrganizar los distintos tipos de códigoArchivos de apoyo al proyectoPruebas entre proyectosProyectos dedicados a pruebas de integraciónOrganizar el código por concepto de dominioOrganizar los archivos de valores de configuraciónGestionar la infraestructura y el código de las aplicacionesProporcionar infraestructura y aplicacionesProbar aplicaciones con infraestructuraProbar la infraestructura antes de integrarlaUso del Código de Infraestructura para la Implementación de AplicacionesConclusión
Código de ejecución de infraestructurasConstruir un proyecto de infraestructurasEmpaquetar el código de la infraestructura como un artefactoUtilizar un repositorio para entregar código de infraestructuraIntegrar proyectosPatrón: Integración de proyectos Build-TimePatrón: Integración del proyecto en el plazo de entregaPatrón: Integración del Proyecto Aplicar-TiempoUtilizar scripts para envolver herramientas de infraestructuraEnsamblar valores de configuraciónSimplificar los scripts envoltorioConclusión
El pueblo¿Quién escribe el código de la infraestructura?Aplicar el código a la infraestructuraAplicar el código desde tu estación de trabajo localAplicar código desde un servicio centralizadoInstancias de infraestructura personalRamas del código fuente en los flujos de trabajoEvitar la deriva de la configuraciónMinimiza el retraso en la automatizaciónEvitar la aplicación ad hocAplicar código continuamenteInfraestructura inmutableGobernanza en un flujo de trabajo basado en pipelinesReorganización de responsabilidadesDesplazamiento a la izquierdaUn ejemplo de proceso para la infraestructura como código con gobernanzaConclusión
Reduce el alcance del cambioPequeños cambiosEjemplo de refactorizaciónEmpujar cambios incompletos a producciónInstancias paralelasTransformaciones retrocompatiblesConmutadores de funcionesCambiar la infraestructura en vivoCirugía de infraestructurasExpandir y contraerCambios sin tiempo de inactividadContinuidadContinuidad evitando erroresContinuidad mediante recuperación rápidaRecuperación continua en caso de catástrofeIngeniería del caosPlanificar el fracasoContinuidad de los datos en un sistema cambianteCerraduraSegregaReplicarRecargaMezclar enfoques de continuidad de datosConclusión

Content preview from Infraestructura como código, 2ª edición

Capítulo 12. Gestión de cambios en los servidores

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Muchas organizaciones y equipos se centran en los procesos y herramientas para crear servidores y otras infraestructuras, pero descuidan los cambios. Cuando se necesita un cambio -para solucionar un problema, aplicar parches de seguridad o actualizar el software-, lo tratan como un acontecimiento inusual. Si cada cambio es una excepción, entonces no puedes automatizarlo. Esta mentalidad es la causa de que tantas organizaciones tengan sistemas incoherentes y defectuosos. Es la razón por la que muchos de nosotros pasamos nuestro tiempo alternando entre recoger tickets aburridos y apagar fuegos.

Lo único constante de nuestros sistemas es que cambian. Si definimos nuestros sistemas como código, los ejecutamos en plataformas de infraestructura dinámicas y distribuimos ese código a través de nuestros sistemas con una canalización de cambios, entonces podemos hacer que los cambios sean rutinarios y fáciles. Si nuestros sistemas sólo se crean y cambian mediante código y canalizaciones, entonces podemos garantizar su coherencia y estar seguros de que se ajustan a las políticas que necesitemos.

"Qué hay en un servidor" y "De dónde vienen las cosas" describen qué hay en un servidor y de dónde viene todo. Todo lo que hay en un determinado servidor procede de una fuente definida, ya sea una instalación del SO, un repositorio ...