One place for hosting & domains

      Recomendadas

      Introducción a prácticas recomendadas de CI/CD


      Introducción

      La integración, entrega e implementación continuas, conocidas en conjunto como CI/CD, son una parte integral del desarrollo moderno que pretende reducir los errores durante la integración y la implementación mientras se aumenta la velocidad del proyecto. CI/CD es una filosofía y un conjunto de prácticas a menudo aumentadas por herramientas sólidas que enfatizan las pruebas automatizadas en cada etapa del proceso de software. Al incorporar estas ideas en su práctica, puede reducir el tiempo necesario para integrar los cambios para una versión y probar en profundidad cada cambio antes de pasar a la producción.

      La CI/CD tiene muchos beneficios potenciales, pero para una implementación exitosa a menudo se requiere mucho análisis. Sin un método de ensayo y error exhaustivo, definir exactamente la forma de usar las herramientas y los cambios que puede necesitar en sus entornos o procesos puede ser un desafío. Sin embargo, aunque todas las implementaciones son diferentes, ceñirse a las mejores prácticas puede servirle para evitar problemas comunes y lograr mejoras de manera más rápida.

      En esta guía, presentaremos algunas pautas básicas sobre cómo implementar y mantener un sistema de CI/CD para satisfacer mejor las necesidades de su organización. Abarcaremos varias prácticas que le servirán para mejorar la efectividad de su servicio de CI/CD. No dude en leer el documento completo o ir directamente a las áreas que le interesen.

      Procure que sus procesos sean rápidos

      Los procesos de CI/CD ayudan a guiar los cambios a través de ciclos de prueba automatizados, hacia entornos de ensayo y, finalmente, hacia la producción. Cuanto más completos sean sus procesos de prueba, mayor será la garantía de que los cambios no introducirán efectos secundarios imprevistos en su implementación de producción. Sin embargo, dado que cada cambio debe pasar por este proceso, preservar la velocidad y confiabilidad de sus procesos es increíblemente importante para no inhibir la velocidad de desarrollo.

      Equilibrar la tensión entre estos dos requisitos puede ser difícil. Hay algunos pasos sencillos que puede seguir para mejorar la velocidad; por ejemplo, ampliar su infraestructura de CI/CD y optimizar las pruebas. Sin embargo, con el paso del tiempo, puede verse obligado a tomar decisiones críticas sobre el valor relativo de las diferentes pruebas y la etapa o el orden en que se ejecutan. A veces, reducir el conjunto de pruebas eliminando las pruebas de bajo valor o con conclusiones indeterminadas es la forma más inteligente de mantener la velocidad requerida por procesos muy utilizados.

      Al tomar estas decisiones significativas, asegúrese de entender y documentar las compensaciones que realice. Consulte a miembros del equipo y a partes interesadas para alinear las suposiciones del equipo respecto de lo que se espera del conjunto de pruebas y de cuáles deben ser las áreas de enfoque principales.

      Aísle y proteja su entorno de CI/CD

      Desde el punto de vista de la seguridad operativa, su sistema de CI/CD representa una de las infraestructuras que con mayor empeño se deben proteger. Dado que el sistema de CI/CD tiene acceso completo a su base de códigos y credenciales para la implementación en varios entornos, es esencial protegerlo para cuidar los datos internos y garantizar la integridad de su sitio o producto. Debido a su alto valor como objetivo, es importante aislar y bloquear su CI/CD todo lo posible.

      Los sistemas de CI/CD deben implementarse en redes internas protegidas, sin exposición a terceros. Se recomienda configurar de VPN u otra tecnología de control de acceso a la red para garantizar que solo los operadores autenticados puedan acceder a su sistema. Según la complejidad de la topología de su red, su sistema de CI/CD puede necesitar acceder a varias redes diferentes para implementar código en diferentes entornos. Si no cuenta con la protección o el aislamiento correspondiente, los atacantes que obtengan acceso a un entorno pueden ser capaces de practicar saltos de un punto a otro, una técnica utilizada para ampliar el acceso aprovechando las reglas de red internas más indulgentes, a fin de obtener acceso a otros entornos a través de los puntos débiles de sus servidores CI/CD.

      Las estrategias de aislamiento y seguridad requeridas dependerán en gran medida de la topología e infraestructura de su red y de sus requisitos de administración y desarrollo. El punto importante que se debe tener en cuenta es que sus sistemas de CI/CD son objetivos muy valiosos y, en muchos casos, tienen un amplio grado de acceso a sus otros sistemas esenciales. Blindar todos los accesos externos a los servidores y controlar de forma estricta los tipos de acceso interno permitidos ayudarán a reducir el riesgo de que su sistema de CI/CD se vea comprometido.

      Haga que el proceso de CI/CD sea la única forma de realizar implementaciones en la producción

      Parte de lo que hace posible que CI/CD mejore sus prácticas de desarrollo y la calidad de su código es que las herramientas a menudo permiten aplicar las prácticas recomendadas para la prueba y la implementación. La promoción del código a través de sus procesos de CI/CD requiere que cada cambio demuestre que cumple con los estándares y procedimientos codificados de su organización. Las fallas en un proceso de CI/CD se pueden ver de inmediato y detienen el avance de la versión afectada hasta etapas posteriores del ciclo. Este es un mecanismo de control de acceso que protege los entornos más importantes contra códigos no confiables.

      Sin embargo, para obtener estas ventajas es necesario ser disciplinado a fin de garantizar que cada cambio en su entorno de producción pase por su proceso. El proceso de CI/CD debería ser el único mecanismo por el cual el código ingresa en el entorno de producción. Esto puede suceder automáticamente al final de las pruebas exitosas con prácticas de implementación continua o mediante una promoción manual de cambios probados aprobados y puestos a disposición por su sistema de CI/CD.

      Con frecuencia, los equipos comienzan a utilizar sus procesos para la implementación, pero empiezan a hacer excepciones cuando se producen problemas y hay presión para resolverlos rápidamente. Si bien es necesario resolver problemas como el tiempo de inactividad y otros lo más pronto posible, es importante entender que el sistema de CI/CD es una buena herramienta para garantizar que sus cambios no introduzcan otros errores ni generen aún más daños en el sistema. Poner su solución mediante el proceso (o simplemente usar el sistema de CI/CD para retroceder) también evitará que en la próxima implementación se borre una corrección ad hoc aplicada directamente a la producción. El proceso protege la validez de sus implementaciones, independientemente de si se trata de una versión regular y planificada o una solución rápida para resolver un problema en curso. Este uso del sistema de CI/CD es otra razón más para procurar que su proceso sea rápido.

      Mantenga la paridad con la producción siempre que sea posible

      Los procesos de CI/CD promueven cambios mediante una serie de conjuntos de pruebas y entornos de implementación. Los cambios que superan los requisitos de una etapa se implementan automáticamente o se ponen en cola para su implementación manual en entornos más restrictivos. Las primeras etapas tienen por objeto demostrar que vale la pena seguir probando e impulsando los cambios más cerca de la producción.

      En particular para las etapas posteriores, reproducir el entorno de producción de la manera más fidedigna posible en los entornos de pruebas ayuda a garantizar que estas últimas reflejen con precisión el comportamiento que tendría el cambio en la producción. Las diferencias significativas entre la puesta en escena y la producción pueden permitir que se liberen cambios problemáticos que nunca se observaron en las pruebas. Cuantas más diferencias haya entre su entorno activo y el entorno de pruebas, menos medirán sus pruebas el comportamiento que tendrá el código cuando se libere.

      Se esperan algunas diferencias entre la puesta en escena y la producción, pero es esencial procurar que sean manejables y asegurarse de que se comprendan bien. Algunas organizaciones utilizan implementaciones “blue-green” para intercambiar el tráfico de producción entre dos entornos casi idénticos cuyas designaciones se alternan entre la producción y la puesta en escena. Estrategias menos extremas implican la implementación de la misma configuración e infraestructura desde la producción hasta su entorno de puesta en escena, pero a una escala reducida. Los elementos como los extremos de la red pueden diferir entre sus entornos, pero la parametrización de este tipo de datos variables puede ayudar a garantizar que el código sea coherente y que las diferencias de entorno estén bien definidas.

      Haga el trabajo de compilación solo una vez y transmita el resultado a través del proceso

      Un objetivo principal de un proceso de CI/CD es crear confianza en sus cambios y minimizar la posibilidad de un impacto inesperado. Analizamos la importancia de mantener la paridad entre los ambientes, pero un componente de esto es suficientemente importante como para ameritar atención adicional. Si su software requiere un paso de construcción, empaquetado o agrupación, ese paso se debe ejecutar solo una vez y el resultado obtenido se debe reutilizar a lo largo de todo el proceso.

      Esta guía permite prevenir problemas que surgen cuando el software se compila o empaqueta varias veces, lo cual permite que se inyecten ligeras inconsistencias en los artefactos obtenidos. Construir el software por separado en cada nueva etapa puede significar que las pruebas en entornos anteriores no se dirigían al mismo software que se implementará más tarde, lo que invalida los resultados.

      Para evitar este problema, los sistemas de CI deberían incluir un proceso de construcción como primer paso en el proceso que crea y empaqueta el software en un entorno limpio. El artefacto obtenido debería someterse a un control de versiones y cargarse en un sistema de almacenamiento de artefactos para retirarse en etapas posteriores del proceso, lo cual garantizará que la construcción no cambie a medida que avance en el sistema.

      Realice sus pruebas más rápidas con antelación

      Si bien sostener la velocidad del proceso es un gran objetivo general, algunas partes del conjunto de pruebas serán inevitablemente más rápidas que otras. Debido a que el sistema de CI/CD sirve como un conducto para todos los cambios que ingresan a su sistema, descubrir las fallas lo más pronto posible es importante para minimizar los recursos dedicados a las versiones problemáticas. Para lograr esto, priorice y ejecute sus pruebas más rápidas primero. Guarde las pruebas complejas y de larga duración para después de que validar la construcción con pruebas más pequeñas y de ejecución rápida.

      Esta estrategia tiene una serie de beneficios que pueden servir para que en su proceso de IC/CD no haya problemas. Lo alienta a comprender el impacto en el rendimiento de las pruebas individuales, le permite completar la mayoría de sus pruebas de forma anticipada y aumenta la probabilidad de fallas rápidas, lo cual significa que los cambios problemáticos pueden revertirse o arreglarse antes de bloquear el trabajo de otros miembros.

      Priorizar pruebas normalmente implica ejecutar primero las pruebas unitarias de su proyecto, ya que estas tienden a ser rápidas, aisladas y centradas en los componentes. Después, las pruebas de integración representan normalmente el siguiente nivel de complejidad y velocidad; a estas les siguen pruebas a nivel de todo el sistema y, finalmente, las pruebas de aceptación, que a menudo requieren algún nivel de interacción humana.

      Minimice las ramificaciones en su sistema de control de versiones

      Uno de los principios fundamentales de CI/CD es integrar los cambios en el repositorio primario compartido de forma temprana y frecuente. Esto ayuda a evitar costosos problemas de integración en el futuro cuando varios desarrolladores intentan fusionar cambios grandes, divergentes y conflictivos en la rama principal del repositorio en preparación para su lanzamiento. Normalmente, los sistemas de CI/CD se configuran para monitorear y probar los cambios enviados a solo una o a unas pocas ramas.

      Para aprovechar los beneficios que proporciona la CI, es mejor limitar el número y el alcance de las ramas en su repositorio. La mayoría de las implementaciones sugieren que los desarrolladores realicen la implementación directamente en la rama principal o fusionen los cambios de sus ramas locales al menos una vez al día.

      Básicamente, las ramas de las cuales su sistema de CI/CD no realiza un seguimiento contienen código no probado que debería considerarse como una responsabilidad para el éxito y el impulso de su proyecto. Minimizar las ramificaciones para fomentar la integración temprana del código de diferentes desarrolladores permite aprovechar las fortalezas del sistema y evita que los desarrolladores nieguen las ventajas que proporciona.

      Realice pruebas localmente antes realizar la implementación en el proceso de CI/CD

      En relación con el punto anterior sobre la detección temprana de fallas, se debería animar a los desarrolladores a que ejecuten localmente todas las pruebas posibles antes de la implementación en el repositorio compartido. Esto permite detectar ciertos cambios problemáticos antes de que bloqueen a otros miembros del equipo. Si bien el entorno de desarrollo local probablemente no pueda ejecutar el conjunto de pruebas completo en un entorno de producción, este paso adicional da a los individuos más confianza en que los cambios que realizan superan las pruebas básicas y vale la pena intentar integrarlos con la base de código más grande.

      Para garantizar de que los desarrolladores puedan realizar las pruebas de forma efectiva por sí mismos, su paquete de pruebas debería poder ejecutarse con un único comando que se pueda ejecutar desde cualquier entorno. El sistema CI/CD debería usar el mismo comando que emplean los desarrolladores en sus máquinas locales para iniciar pruebas en código fusionado con el repositorio. A menudo, esto se coordina proporcionando una secuencia de comandos de shell o makefile para automatizar la ejecución de las herramientas de pruebas de una manera repetible y predecible.

      Ejecute pruebas en entornos efímeros cuando sea posible

      Para garantizar que sus pruebas se ejecuten de la misma manera en varias etapas, a menudo se recomienda utilizar entornos de prueba limpios y efímeros cuando sea posible. Normalmente, esto significa ejecutar las pruebas en contenedores para abstraer las diferencias entre los sistemas host y proporcionar una API estándar para acoplar los componentes a varias escalas. Debido a que los contenedores se ejecutan con un estado mínimo, los efectos secundarios residuales de las pruebas no se heredan en las ejecuciones siguientes del conjunto de pruebas, lo que podría contaminar los resultados.

      Otro beneficio de los entornos de pruebas en contenedores es la portabilidad de su infraestructura de pruebas. Con los contenedores, los desarrolladores tienen más facilidad para replicar la configuración que se utilizará más adelante en el proceso sin necesidad de configurar y mantener manualmente la infraestructura, ni de sacrificar la fidelidad de entorno. Dado que los contenedores pueden girarse fácilmente cuando es necesario y luego destruirse, los usuarios pueden hacer menos sacrificios en términos de la precisión de su entorno de pruebas cuando se ejecutan pruebas locales. En general, el uso de contenedores se bloquea en algunos aspectos del entorno de ejecución para ayudar a minimizar las diferencias entre las etapas del proceso.

      Conclusión

      Si bien cada implementación de CI/CD será diferente, aplicar algunos de estos principios básicos le permitirá evitar algunos errores comunes y fortalecer sus prácticas de prueba y desarrollo. Como en la mayoría de los aspectos de la integración continua, una combinación de procesos, herramientas y hábitos permitirá que los cambios vinculados al desarrollo tengan más éxito e impacto.

      Para obtener más información sobre las prácticas generales de CI/CD y la configuración de varios servicios de CI/CD, consulte otros artículos con la etiqueta CI/CD.



      Source link

      Etapas Adicionais Recomendadas para Novos Servidores CentOS 7


      Introdução

      Depois de definir a configuração mínima para um novo servidor, existem algumas etapas adicionais que são altamente recomendadas na maioria dos casos. Neste guia, continuaremos a configuração de nossos servidores, abordando alguns procedimentos recomendados, mas opcionais.

      Pré-requisitos e Objetivos

      Antes de iniciar este guia, você deve passar pelo guia de Configuração Inicial do Servidor com o CentOS 7. Isso é necessário para configurar suas contas de usuário, configurar a elevação de privilégios com o sudo e bloquear o SSH por segurança.

      Depois de concluir o guia acima, você pode continuar com este artigo. Neste guia, nos concentraremos na configuração de alguns componentes opcionais, mas recomendados. Isso envolverá a configuração do nosso sistema com um firewall e um arquivo de swap, e configurar a sincronização do Network Time Protocol.

      Configurando um Firewall Básico

      Os firewalls fornecem um nível básico de segurança para o seu servidor. Esses aplicativos são responsáveis por negar tráfego a todas as portas do servidor com exceções das portas/serviços que você aprovou. O CentOS vem com um firewall chamado firewalld. Uma ferramenta chamada firewall-cmd pode ser usada para configurar suas políticas de firewall. Nossa estratégia básica será bloquear tudo o que não tivermos uma boa razão para manter em aberto. Primeiro instale o firewalld:

      • sudo yum install firewalld

      O serviço firewalld tem a capacidade de fazer modificações sem perder as conexões atuais, assim podemos ativá-lo antes de criar nossas exceções:

      • sudo systemctl start firewalld

      Agora que o serviço está funcionando, podemos usar o utilitário firewall-cmd para obter e definir informações de política para o firewall. O aplicativo firewalld usa o conceito de “zonas” para rotular a confiabilidade dos outros hosts em uma rede. Essa rotulagem nos dá a capacidade de atribuir regras diferentes, dependendo de quanto confiamos em uma rede.

      Neste guia, estaremos ajustando somente as políticas para a zona padrão ou default. Quando recarregarmos nosso firewall, essa será a zona aplicada às nossas interfaces. Devemos começar adicionando exceções ao nosso firewall para serviços aprovados. O mais essencial deles é o SSH, já que precisamos manter o acesso administrativo remoto ao servidor.

      Se você não modificou a porta em que o daemon SSH está sendo executado, é possível ativar o serviço pelo nome digitando:

      • sudo firewall-cmd --permanent --add-service=ssh

      Se você alterou a porta SSH do seu servidor, você terá que especificar a nova porta explicitamente. Você também precisará incluir o protocolo que o serviço utiliza. Somente digite o seguinte caso seu servidor SSH já tenha sido reiniciado para usar a nova porta:

      • sudo firewall-cmd --permanent --remove-service=ssh
      • sudo firewall-cmd --permanent --add-port=4444/tcp

      Isso é o mínimo necessário para manter o acesso administrativo ao servidor. Se você planeja executar serviços adicionais, também precisa abrir o firewall para esses serviços.

      Se você planeja executar um servidor web HTTP convencional, você precisará habilitar o serviço http:

      • sudo firewall-cmd --permanent --add-service=http

      Se você planeja executar um servidor web com SSL/TLS ativado, você também deve permitir o tráfego de https:

      • sudo firewall-cmd --permanent --add-service=https

      Se você precisar que o email SMTP esteja ativado, você pode digitar:

      • sudo firewall-cmd --permanent --add-service=smtp

      Para ver quaisquer serviços adicionais que você possa ativar por nome, digite:

      • sudo firewall-cmd --get-services

      Quando terminar, você poderá ver a lista das exceções que serão implementadas digitando:

      • sudo firewall-cmd --permanent --list-all

      Quando você estiver pronto para implementar as mudanças, recarregue o firewall:

      • sudo firewall-cmd --reload

      Se, após o teste, tudo funcionar conforme o esperado, você deverá certificar-se de que o firewall será iniciado na inicialização:

      • sudo systemctl enable firewalld

      Lembre-se de que você terá que abrir explicitamente o firewall (com serviços ou portas) para quaisquer serviços adicionais que você venha a configurar posteriormente.

      Configurar Fuso Horário e Sincronização do Network Time Protocol

      O próximo passo é ajustar as configurações de localização do seu servidor e configurar a sincronização do Network Time Protocol (NTP).

      O primeiro passo garantirá que seu servidor esteja operando no fuso horário correto. O segundo passo configurará seu servidor para sincronizar o relógio do sistema com o horário padrão mantido por uma rede global de servidores NTP. Isso ajudará a evitar algum comportamento inconsistente que pode surgir com relógios fora de sincronia.

      Configurar Fusos Horários

      Nosso primeiro passo é definir o fuso horário do nosso servidor. Este é um procedimento muito simples que pode ser realizado usando o comando timedatectl:

      Primeiro, dê uma olhada nos fusos horários disponíveis digitando:

      • sudo timedatectl list-timezones

      Isto lhe dará uma lista dos fusos horários disponíveis para o seu servidor. Quando você encontrar a configuração de região/fuso horário que estiver correta para o seu servidor, defina-a digitando:

      • sudo timedatectl set-timezone região/fuso_horário

      Por exemplo, para configurá-lo para o horário do leste dos Estados Unidos, você pode digitar:

      • sudo timedatectl set-timezone America/New_York

      Seu sistema será atualizado para usar o fuso horário selecionado. Você pode confirmar isso digitando:

      Configurar a Sincronização NTP

      Agora que você tem o seu fuso horário definido, devemos configurar o NTP. Isso permitirá que seu computador fique em sincronia com outros servidores, levando a uma maior previsibilidade nas operações que dependem da hora correta.

      Para a sincronização NTP, usaremos um serviço chamado ntp, que podemos instalar a partir dos repositórios padrão do CentOS:

      Em seguida, você precisa iniciar o serviço para esta sessão. Também habilitaremos o serviço para que ele seja iniciado automaticamente sempre que o servidor for inicializado:

      • sudo systemctl start ntpd
      • sudo systemctl enable ntpd

      Seu servidor agora corrigirá automaticamente o relógio do sistema para se alinhar aos servidores globais.

      Criar um Arquivo de Swap

      Adicionar "swap" a um servidor Linux permite que o sistema mova as informações acessadas por um programa em execução com menos frequência da RAM para um local no disco. Acessar os dados armazenados no disco é muito mais lento do que acessar a RAM, mas ter o swap disponível pode ser a diferença entre o aplicativo permanecer ativo e a falha. Isso é especialmente útil se você planeja hospedar bancos de dados em seu sistema.

      Conselhos sobre o melhor tamanho para um espaço de swap variam significativamente dependendo da fonte consultada. Geralmente, um valor igual ou o dobro da quantidade de RAM do seu sistema é um bom ponto de partida.

      Aloque o espaço que você deseja usar para o seu arquivo de swap usando o utilitário fallocate. Por exemplo, se precisarmos de um arquivo de 4 Gigabytes, podemos criar um arquivo de swap localizado em /swapfile digitando:

      • sudo fallocate -l 4G /swapfile

      Depois de criar o arquivo, precisamos restringir o acesso a ele para que outros usuários ou processos não consigam ver o que é gravado lá:

      Agora temos um arquivo com as permissões corretas. Para dizer ao nosso sistema para formatar o arquivo para swap, podemos digitar:

      Agora, diga ao sistema que ele pode usar o arquivo de swap digitando:

      Nosso sistema está usando o arquivo de swap para esta sessão, mas precisamos modificar um arquivo de sistema para que nosso servidor faça isso automaticamente na inicialização. Você pode fazer isso digitando:

      • sudo sh -c 'echo "/swapfile none swap sw 0 0" >> /etc/fstab'

      Com essa adição, seu sistema deve usar seu arquivo de swap automaticamente a cada inicialização.

      Para Onde Ir a partir Daqui?

      Agora você tem uma configuração inicial muito decente para o seu servidor Linux. A partir daqui, existem alguns lugares que você pode ir. Primeiro, você pode querer tirar um instantâneo ou snapshot do seu servidor em sua configuração atual.

      Tirando um Snapshot da sua Configuração atual

      Se você está satisfeito com sua configuração e deseja usar isso como uma base para futuras instalações, você pode tirar um snapshot do seu servidor através do painel de controle da DigitalOcean. A partir de outubro de 2016, os snapshots custam $0.05 por gigabyte por mês, com base na quantidade de espaço utilizado no sistema de arquivos.

      Para fazer isso, desligue seu servidor pela linha de comando. Embora seja possível fazer um snapshot de um sistema em execução, o desligamento garante que os arquivos no disco estejam todos em um estado consistente:

      Agora, no painel de controle da DigitalOcean, você pode tirar um snapshot visitando a guia "Snapshots" do seu servidor:

      DigitalOcean snapshot

      Depois de tirar seu snapshot, você poderá usar essa imagem como base para instalações futuras, selecionando o snapshot a partir da guia "My Snapshots" para imagens durante o processo de criação:

      DigitalOcean use snapshot

      Recursos Adicionais e Próximos Passos

      A partir daqui, o seu caminho depende inteiramente do que você deseja fazer com o seu servidor. A lista de guias abaixo não é de forma alguma exaustiva, mas representa algumas das configurações mais comuns que os usuários recorrem:

      Conclusão

      Nesse ponto, você deve saber como configurar uma base sólida para seus novos servidores. Espero que você também tenha uma boa ideia para os próximos passos. Sinta-se à vontade para explorar o site para mais ideias que você pode implementar em seu servidor.



      Source link