DEV Community: Rossana Suarez #RoxsRoss

Ruta hacia el Éxito: Migración de Amazon RDS (PostgreSQL) entre Cuentas en AWS sin Contratiempos

Rossana Suarez #RoxsRoss — Wed, 03 Jan 2024 23:34:57 +0000

*Bienvenidos a nuestra guía exclusiva sobre la migración de Amazon RDS (PostgreSQL) entre cuentas en AWS. *

En el siempre dinámico entorno de la computación en la nube, la capacidad de mover recursos de manera eficiente se ha vuelto esencial.

Si te encuentras en la encrucijada de trasladar tu base de datos PostgreSQL alojada en Amazon RDS de una cuenta AWS a otra, estás en el lugar adecuado.

En esta travesía, desmitificaremos el proceso, exploraremos estrategias efectivas y proporcionaremos consejos prácticos para asegurar una migración sin contratiempos.

Prepárate para emprender la ruta hacia el éxito en tu migración en la nube, donde cada paso está diseñado para optimizar tu experiencia y garantizar el funcionamiento continuo de tu base de datos en PostgreSQL.

Overview

Inicia sesión en la cuenta de origen y crea un snapshot desde RDS.
Crea una clave KMS (con detalles de la cuenta de destino).
Después de crear el snapshot, realiza una copia nueva del snapshot y adjunta la clave KMS.
Comparte el snapshot recién creada con la cuenta de destino.
Inicia sesión en la cuenta de destino, ve a snapshot compartidas conmigo "Shared with me" y crea una nueva copia de la instantánea.
Restaura el snapshot copiada en una nueva instancia de RDS.

Migración de base de datos

Guía paso a paso para compartir de manera sencilla tu Amazon RDS en solo 6 pasos

1.- Inicia sesión en la cuenta de origen y crea un snapshot desde RDS.

En la cuenta origen Account xxxx-xxxx-6849 , Region us-east-1, vamos a crear una base de datos con el engine PostgresSQL y creamos AWS-RDS-MIGRATE-DEMO

Ahora creamos el snapshot desde la cuenta de origen aws-rds-migrate-demo-source-snapshot

Importante: No se puede compartir un snapshot al momento, Para eso tenemos la clave KMS al rescate.

2- Crea una clave KMS (con detalles de la cuenta de destino).

Vamos ahora al servicio AWS ( KMS )

Cree una clave simétrica y agregue una etiqueta aws-rds-migrate-kms junto con el permiso.

Ingrese el ID de la cuenta de AWS y guarde la clave KMS.

En este caso mi cuenta destino es xxxx-xxxx-4553 en la region us-east-1

Ingrese el ID de la cuenta de AWS y guarde la clave KMS.

3- Comparte el snapshot recién creada con la cuenta de destino

Una vez creado el snapshot, seleccione el snapshot, haga clic en Acciones > Copiar snapshot.

Proporcione un nombre y seleccione la nueva clave KMS

4- Comparte el snapshot recién creada con la cuenta de destino.

Una vez creada la copia "snapshot", haga clic en Acciones > Compartir Snaphot "shared snapshot"

Proporcione la clave de la cuenta de AWS y haga clic en Guardar.

5- Inicia sesión en la cuenta de destino, ve a snapshot compartidas conmigo "Shared with me" y crea una nueva copia del snapshot.

En la cuenta de AWS destino xxxx-xxxx-4553, en la región us-east-1

El Snapshot que hemos compartido desde la cuenta de origen estará disponible en la pestaña Compartido conmigo en la ventana de instantáneas de AWS RDS.

Cree una copia del Snapshot, haga clic en Acciones > Copiar Snapshot

6- Restaura el snapshot copiada en una nueva instancia de RDS.

En la cuenta de AWS destino xxxx-xxxx-4553, en la región us-east-1

Una vez creada la copia del Snapshot , podemos restaurarla.

Seleccione la instantánea, haga clic en Acciones > Restaurar Snapshot

Proporcione los detalles de la nueva RDS y ¡¡listo!!.

“¡Si este artículo fue una bomba de conocimiento para ti, no te limites con un solo aplauso, ¡déjanos sentir el calor con una tormenta de 👏! Comparte el fuego y síguenos para disfrutar de más contenido explosivo sobre DevOps. ¡Juntos, hagamos que la comunidad arda con el poder del desarrollo y las operaciones!" 🔥🚀 "

Conclusión

La migración de Amazon RDS entre cuentas en AWS es un proceso clave que requiere cuidadosa planificación y ejecución. La transferencia exitosa de datos de una cuenta a otra no solo implica la manipulación de Snapshot y claves de cifrado, sino también la gestión efectiva de permisos, políticas IAM y configuraciones de red.

Al seguir una guía detallada y asegurarse de que todas las dependencias, como las claves KMS y las Snapshots, estén correctamente configuradas y disponibles en ambas cuentas, se puede minimizar el riesgo de errores y garantizar una migración sin contratiempos.

Es esencial contar con un enfoque paso a paso, desde la creación de Snapshots en la cuenta de origen hasta la restauración en una nueva instancia en la cuenta de destino. Además, la colaboración entre equipos y la verificación de permisos son aspectos críticos para superar posibles obstáculos durante el proceso.

En última instancia, al seguir las mejores prácticas y mantener una comunicación efectiva entre los equipos involucrados, la migración de Amazon RDS entre cuentas puede realizarse con éxito, brindando la flexibilidad y eficiencia necesarias para adaptarse a los requisitos cambiantes de las infraestructuras en la nube.

Documentación

RDS snapshot migration

Encrypted Amazon RDS DB snapshot

Tutorial

Conéctate en LinkedIn:https://www.linkedin.com/in/roxsross/

Descubre más en GitHub: https://github.com/roxsross

Mi Web: https://roxs.295devops.com

¡Hasta la próxima ola del conocimiento!

Docker vs Podman: ¡Todo lo que necesitas saber!

Rossana Suarez #RoxsRoss — Thu, 02 Feb 2023 20:13:04 +0000

Sin lugar a dudas la tecnología de contenedores ha supuesto toda una revolución. Y dentro de los actores que se encuentran presentes en la escena, el que ha destacado desde el principio es Docker 🐳.

Contenedores

Los contenedores permiten que una aplicación se ejecute de forma consistente y confiable, independientemente del sistema operativo o del ambiente de infraestructura. Los contenedores logran esto agrupando todo lo que un servicio necesita para ejecutarse (el código, el tiempo de ejecución, las herramientas del sistema, las bibliotecas del sistema y la configuración) y crean un paquete portátil, independiente y ejecutable.

Ventajas de un Contenedor

Evita fallos
División de componentes
Bajo coste
Agilidad
Escalabilidad

Los contenedores tienen la característica de servir como base para las aplicaciones nativas de la nube, contribuyendo así a alcanzar un modelo cooperativo entre entornos, tanto de cloud privadas o públicas, como híbridas.

Herramientas que te permite la Contenerización

Docker

La idea detrás de Docker es crear contenedores ligeros y portables para las aplicaciones software que puedan ejecutarse en cualquier máquina con Docker instalado, independientemente del sistema operativo que la máquina tenga por debajo, facilitando así también los despliegues.

Documentación

Podman

Podman es una herramienta nativa para Linux, de código abierto y que no utiliza ningún demonio ni procesos en segundo plano, pensada y diseñada para facilitar la búsqueda, ejecución, construcción, compartición y despliegue de aplicaciones utilizando la tecnología de contenedores e imágenes Open Containers Initiative (OCI).

Documentación

Docker vs Podman: ¡Todo lo que necesitas saber!

¿Por qué Podman vs Docker?

Si observamos las tendencias de Google, vemos que el interés de búsqueda de Podman está en constante aumento. Es probable que veamos a Podman volverse más popular en los próximos años.

https://trends.google.com/trends/explore?q=Podman

Docker sigue siendo un jugador líder en el campo, y no creo que vaya a ninguna parte en el corto plazo, pero los gráficos nos dicen que el interés general en Docker está disminuyendo.

O los desarrolladores están perdiendo interés en Docker o han migrado a otro software que podría hacer su trabajo mejor que Docker.

https://trends.google.com/trends/explore?q=Docker

Podman está basado en Docker y fue originalmente concebido como una herramienta de debugging que terminó convirtiéndose en una alternativa o sucesor a las antiguas herramientas de gestión.

Para facilitar la transición de uno a otro, Podman reconoce y permite utilizar los comandos de Docker. Pero esto por sí solo no convierte a Podman en un sucesor equivalente.

Docker vs Podman | Podman vs Docker. ¿qué los diferencia?

Hay que realizar una comparación directa entre ambos sistemas si queremos poder determinar si triunfa el cuasi-estándar que ha sido popular durante años o el contendiente del duelo Docker vs. Podman

Ahora vamos para probar Docker y Podman desde AWS EC2

Empecemos a jugar...

Estaremos usando AWS CloudShell porque puedes ejecutar AWS CLI para trabajar con los servicios de AWS Y puede hacerlo sin necesidad de descargar o instalar herramientas

https://docs.aws.amazon.com/es_es/cloudshell/latest/userguide/welcome.html

En esta oportunidad vamos a estar instalando terraform para aprovisionar 2 instancias de AWS EC2 una con Docker y otra con Podman

Requisitos:

Cuenta AWS
Recuerden usar siempre la capa gratuita
Terraform install
Credenciales Programáticas AWS
Tfenv
Ficheros Terraform
UserData Docker
UserData Podman

Todo en el Repositorio: https://gitlab.com/roxsross-public/295devops-practice-tools/-/tree/main/Containerization-Tools

Pasos

Si bien usas AWS CloudShell o desde tu terminal puedes correr esta excelente utilidad se llama tfenv.

¿Porque Tfenv?

Cuando trabajas en grandes entornos gestionados con terraform, es muy probable que tengas que trabajar a su vez con diferentes versiones de terraform, según requieran cada unos de los proyectos.

En lugar de descargar las diferentes versiones que necesitemos, renombrando los ejecutables, moviéndolos a algún directorio dentro del PATH y jugando con enlaces simbólicos, podemos símplemente usar el maravilloso tfenv.

Documentacion TFENV

Ahora si vamos aprovisionar las instancias AWS EC2 con Terraform

Dentro de los Ficheros Terraform

Van encontrar un tfvars que nos permite definir la configuración especifica del entorno

Al tener un entorno local para hacer pruebas en Terraform te puedes ayudar de un archivo llamado values.tfvars para hospedar ahí todas las variables que requieres al trabajar.

En el Repositorio encontraran el fichero Value.tfvars.

En ese fichero tienen que reemplazar los siguientes datos a su cuenta en AWS.

app                    = "container"
region                 = "us-east-1"
ec2_instance_type      = "t2.micro"
ec2_key_name           = "295" #Reemplazar
ec2_security_group_id  = "sg-04627cd5684f351cc" #Reemplazar
ec2_ami                = "ami-06878d265978313ca"

Luego realizaron el cambio solo deben inicializar el directorio de terraform:

Inicializar: terraform init

Validar Terraform: terraform validate

Plan: terraform plan –var-file values.tfvars -out plan.out

Apply: terraform apply "plan.out"

El resultado "output" es la siguiente:

Docker IP (public):  18.205.243.235
Docker IP (private): 172.31.82.169

For example:
   ssh -i 295.pem ubuntu@18.205.243.235

Podman IP (public):  3.88.169.4
Podman IP (private): 172.31.95.6

For example:
   ssh -i 295.pem ubuntu@3.88.169.4

Pueden acceder a las instancias desde cualquier cliente SSH, desde SSM o simplemente nos vamos a la terminal de AWS CloudShell

Ahora probar ambas herramientas

Docker

Antes que nada vamos a la documentación para revisar su Docker Cheat Sheet Documentación

Verificar que Docker se este ejecutando.
$ docker version

Algunos Comandos útiles para Docker

Lista de imágenes $ docker image ls
Elimina una imagen específica $ docker image rm [nombre de la imagen]
Elimina todas las imágenes existentes $ docker image rm $(docker images -a -q)
Lista todos los contenedores existentes (en funcionamiento y no en funcionamiento) $ docker ps -a
Detener un contenedor específico $ docker stop [nombre del contenedor]
Detener todos los contenedores en funcionamiento $ docker stop $(docker ps -a -q)
Elimina un contenedor específico (solo si está detenido) $ docker rm [nombre del contenedor]
Elimina todos los contenedores (solo si están detenidos) $ docker rm $(docker ps -a -q)
Mostrar los registros de un contenedor $ docker logs [nombre del contenedor]

Crear el archivo Dockerfile

Dockerfile Docker

Construye

docker build -t nginx_web:docker-1.0.0 .

Corre la imagen, una vez la imagen esté creada, tu código está listo para lanzar.

$ docker run -d -p 8080:80 nginx_web:docker-1.0.0

Podman

Antes que nada vamos a la documentacion para revisar su Podman Cheat Sheet

Revisamos la Version:

ubuntu@ip-172-31-95-6:~$ podman version
Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64

Si queremos conocer los comando podman, apuntemos a la ayuda.

podman -help

Listado "Resumen"

Available Commands:
  build       Build an image using instructions from Containerfiles
  cp          Copy files/folders between a container and the local 
  help        Help about any command
  image       Manage images
  images      List images in local storage
  inspect     Display the configuration of object denoted by ID
  network     Manage networks
  port        List port mappings or a specific mapping for the container
  ps          List containers
  pull        Pull an image from a registry
  push        Push an image to a specified destination
  rm          Remove one or more containers
  rmi         Removes one or more images from local storage
  run         Run a command in a new container
  search      Search registry for image
  start       Start one or more containers
  stop        Stop one or more containers
  version     Display the Podman version information
  volume      Manage volumes

Podemos especificar el registry si queremos buscarlo en docker-hub docker.io

Si usas el comando podman search te permite buscar imágenes en uno o varios registros. Puedes especificar en que registro quieres buscar alñadiendo el registro en el término de búsqueda. Por defecto, buscará en los registros que se encuentrend definidos en /etc/containers/registries.conf. En mi caso, por ejemplo, el contenido de este archivo es.

[registries.search]
registries = ['docker.io', 'quay.io']

Un pequeño flujo usando la imagen de apache:

podman pull docker.io/library/httpd
podman run -dt --name apache-web -p 8080:80 docker.io/library/httpd 
podman ps
podman rm apache-web

Y si queremos contruir nuestras imagenes usando el build si contamos con el Dockerfile en el directorio de trabajo pueden construir sin problemas.

Dockerfile Podman

podman build -t nginx_web:podman-1.0.0 .

Salida:

ubuntu@ip-172-31-95-6:~/$ podman images
REPOSITORY               TAG            IMAGE ID      CREATED        SIZE
localhost/nginx_web      podman-1.0.0   f43bf88b8923  2 minutes ago  101 MB

Ahora vamos a ejecutarlo

podman run -d 8080:80 nginx_web:podman-1.0.0

ubuntu@ip-172-31-95-6:~/$ podman ps
CONTAINER ID  IMAGE                             COMMAND               CREATED         STATUS             PORTS                   NAMES
3e419ed245a9  localhost/nginx_web:podman-1.0.0  sh -c date ; npm ...  5 seconds ago   Up 6 seconds ago   0.0.0.0:8080->80/tcp  dazzling_ganguly

Para resumir

Desde mi punto de vista, especialmente en cuanto a la seguridad; mientras Docker lleva mucho tiempo intentando ponerse al día en este aspecto, estas deficiencias se han subsanado desde el principio con Podman.

La ausencia de un daemon centralizado y la mejor protección resultante de ello podrían convencer tarde o temprano.

Pero sin embargo, ni siquiera Podman se libra de tener errores; todavía necesita resolver algunos problemas. Si se resuelven estos pequeños problemas con éxito, Podman ganará a Docker por un margen estrecho.

Ahora les pregunto…. ¿Puede Podman verdaderamente sustituir a Docker?

VIDEO

Docker 🐳, AWS Elastic Container Registry (ECR)

Rossana Suarez #RoxsRoss — Thu, 02 Feb 2023 19:33:10 +0000

Si es nuevo en Containers, esto es para tí

1. ¿Qué es un contenedor?

Un contenedor pude definirse como un tipo de máquina virtual ligera o paquete de software estándar que se encarga de las labores de virtualización de las diferentes aplicaciones en lugar de máquinas completas.

Esto lo consigue agrupando una aplicación e incluyendo todos los archivos que se necesiten para funcionar en un entorno de ejecución, como, por ejemplo, el código de la app con sus bibliotecas y archivos de configuración que se encuentren asociados, así como las dependencias que permiten la ejecución de la aplicación.

Un contenedor se establece en el sistema como una sola unidad, por lo que tiene mucha mayor facilidad para desplazarse y ser ejecutado en cualquier sistema operativo, sin importar el contexto. Además, esta tecnología contribuye a que los desarrolladores tengan la capacidad de implementar una gran variedad de aplicaciones sin presentar problemas en todos los entornos.

deed-dive-containers

2. Ventajas de un contenedor

- Evita fallos
Los usuarios evitan fallos como los bloqueos producto a los entornos incompatibles, lo que permite que el sistema obtenga un rendimiento uniforme para todos los equipos.

- División de componentes
Otra de las ventajas de estos elementos es que, sin un sistema operativo, tiene la posibilidad de proporcionar una forma más eficiente para que los desarrolladores puedan desplegarlos en clúster.

- Bajo coste
Los costes de los containers también representan una ventaja para el desarrollador, debido a que consumen pocos gastos generales, lo que permite que los recursos del proyecto tecnológico o compañía puedan destinarse a otros elementos que pueden mejorar el rendimiento y la eficiencia de los procesos del sistema.

- Agilidad
Otra de las principales ventajas del uso de los contenedores es su agilidad, ya que cuando se realizan los procesos de compilación y empaquetado en contenedores y se ejecutan en una plataforma normalizada, el esfuerzo global referente a la implementación de aplicaciones en el sistema se reduce ampliamente. De igual forma, estas acciones contribuyen a optimizar la totalidad de los ciclos de desarrollo y prueba.

- Escalabilidad
La escalabilidad rápida de los contenedores se debe a que estos no tienen la sobrecarga que suelen incluir las máquinas virtuales (VM), así como las instancias de los sistemas operativos independientes y demás.

Picturesocial – Cómo contenerizar una aplicación en menos de 15 minutos

Herramientas:

Docker Desktop instalado
AWS CLI: Instalado y Credenciales Configuradas
Conocimiento básico de la CLI de Linux
Git/GitHub
IDE (Visual Studio Code, Sublime txt, etc)

El Desafío:

El Team necesita implementar la contenerización de una aplicación nginx

Pasos:

1. Automatizamos con un Script en bash que permita: Crear una carpeta y en ella crea un fichero index.html y Dockerfile usando como imagen base nginx:alpine

#!/bin/bash
mkdir app
cd app
cat > index.html <<EOF
<style>
    body{
        background-color: aquamarine;
    }
</style>
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <link href="site.css" rel="stylesheet" />
</head>
<body>
    <h1>I'm inside of a container. Help!</h1>
</body>
</html>
EOF

cat > Dockerfile <<EOF
FROM nginx:alpine
EXPOSE 8080
COPY index.html /usr/share/nginx/html
EOF

Conozcamos algunos de los componentes dentro del archivo Dockerfile.

FROM nos permite especificar a partir de qué imagen base de Docker Hub queremos construir. En nuestro caso, estamos utilizando la última versión de la nginx:alpine oficial.

EXPOSE esto expondrá los puertos en los que escuchará el contenedor.

COPY es bastante sencillo y nos permite copiar archivos o un directorio completo desde un host a un destino. Vamos al COPY archivo index.html a nuestro directorio de trabajo.

- Construcción de nuestra imagen 🔥

Tenemos todo lo que necesitamos para crear construir nuestra aplicación y que luego usaremos para iniciar un contenedor.

Docker intentará encontrar un archivo con el nombre Dockerfile dentro del directorio de trabajo y creará una imagen de Docker usando el Dockerfile.

Puede ser difícil de ver, pero el punto (.) indica que Dockerfile está en el directorio actual. Verá por qué esto es relevante cuando envíe la imagen a un ECR de AWS.

<context_dir> = .

docker build -t <imageName> <context_dir> 

#Lo que realmente ejecuté
 docker build -t nginx-app:1.0 .

Si ejecutamos docker images , deberíamos poder identificar nuestra imagen recién creada.

2. Creación del contenedor con el puerto 8080

Ahora que tenemos nuestra imagen, podemos crear un contenedor con el siguiente comando.

docker  run  -d  -p  <puerto_host>:<puerto_contenedor >  \ 
--name <nombre_contenedor  >  \ 
<nombre_imagen>:<etiqueta>

-d Ejecutará el contenedor en 2do plano e imprimirá la ID del contenedor

-p esta opción establece las asignaciones de puertos entre el host y el contenedor.

Resultados 🔥🔥🔥🔥:

Pueden ejecutar htttp://localhost:8080 en su navegador

localhost:8080

Con un curl localhost para probar que podemos acceder a Internet.

3. Enviar imagen a AWS ECR

Amazon Elastic Container Registry (Amazon ECR) es un servicio de registro de imágenes de contenedor administrado por AWS que es seguro, escalable y fiable. Amazon ECR admite repositorios privados con permisos basados en recursos mediante AWS IAM.

Crearemos un repositorio privado para nuestra imagen en AWS ECR

El primer paso será iniciar sesión en la consola de AWS > escribir " ECR " en la barra de búsqueda y seleccionar Comenzar en Crear repositorio.

Hay varias opciones en esta pantalla, como la configuración de visibilidad para hacer que su aplicación sea privada o pública o Habilitar la mutabilidad de etiquetas "tag", lo que evita que las etiquetas de imágenes se sobrescriban con las subsiguientes subidas de imágenes. Lo Recomendable

Una vez creado desde AWS le proporciona los comandos necesarios para enviar su imagen al repositorio. Lo cual lo hace bastante útil ya que la sintaxis no es tan sencilla como crees.

Un requisito previo para este paso es tener la CLI de AWS instalada y las credenciales configuradas; de lo contrario, los comandos no funcionarán

Algunos comandos

*El primer paso es autenticar su Docker Client e iniciar sesión. *

Si esta imagen se creó desde alguna herramienta de cicd como por ejemplo: Jenkins, gitlab-ci, github actions etc , tendría que permitir inicie sesión en el repositorio.

Vamos a autenticarnos

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin ACCOUNT_AWS.dkr.ecr.us-east-1.amazonaws.com

Vamos a tagear

NOTA: Cuando copie el comando, no olvide actualizar la etiqueta de nginx-app:latest a nginx-app:1.0

docker tag nginx-app:1.0 ACCOUNT_AWS.dkr.ecr.us-east-1.amazonaws.com/nginx-app:1.0.0

Subir a ECR

El comando push dice Voy a tomar nginx-app:1.0 y enviarlo al repositorio de AWS ECR.

docker push ACCOUNT_AWS.dkr.ecr.us-east-1.amazonaws.com/nginx-app:1.0.0

Subir a Docker-hub

Docker Hub es el repositorio de imágenes para contenedores más grande del sector IT, ya que aloja la mayor cantidad de imágenes oficiales de la plataforma.

Inicie sesión en Docker Hub mediante un comando.

docker login
docker tag <image_id> <repositry>/<image_name>:<tag>
docker push <repositry>/<image_name>:<tag>

Desde Docker-hub

Si terminastes esta prueba, Elimina contenedores e imágenes con los siguientes comandos.

#Debe detener su contenedor antes de poder eliminarlo
 docker stop <nombre o ID del contenedor> 

#Remove container
 docker rm <nombre o ID del contenedor> 

#No puede eliminar una imagen si un contenedor se está ejecutando en esa imagen

 docker rmi <nombre de la imagen o identificación>

Nota: Puede eliminar un contenedor mientras se ejecuta, pero debe usar la -f para forzarlo.

Demostración: Automaticemos un poco

Documentación
AWS ECR
Docker Build
Docker Doc

Si este contenido te pareció genial, Puedes Contactarme también en Linkedin donde podemos continuar la conversación.

Follow https://github.com/roxsross
Linkedin https://www.linkedin.com/in/roxsross/
Linktree https://roxs.295devops.com

Despliega un clúster de Kubernetes en segundos con k3sup

Rossana Suarez #RoxsRoss — Tue, 10 Jan 2023 03:33:22 +0000

Kubernetes es una herramienta de código abierto que se encarga de la orquestación de contenedores. Automatiza la implementación de contenedores, el escalado y desescalado continuo, el equilibrio de carga de contenedores, etc.

Hay varias plataformas en la nube que ofrecen Kubernetes como servicio. Estas plataformas facilitan el trabajo al proporcionar una interfaz que facilita el despliegue de aplicaciones en Kubernetes sin tener que preocuparse por la configuración y gestión de los distintos componentes del clúster. Algunas de ellas son: Amazon EKS, Digitalocean, OpenShift o Rancher, entre otras.

Cito a José Yapur, Senior Developer Advocate en AWS

Un orquestador de containers es el que está a cargo de manejar todos los containers, réplicas, redes, almacenamiento y en general la infraestructura necesaria. El orquestador de contenedores más popular es Kubernetes gracias a su comunidad activa, soporte y ecosistema de integración.

https://aws.amazon.com/es/blogs/aws-spanish/picturesocial-que-es-kubernetes-y-por-que-deberia-importarme/

Pero en nuestra ruta de aprendizaje necesitamos comenzar a conocer sobre este gran ecosistema de forma local.

Top 6 de Herramientas para desplegar un cluster local

✅️1- Minikube

https://lnkd.in/dfXaQ2kN

✅️2- K3s: Kubernetes más simple

https://k3s.io/

✅️3- K3D

https://k3d.io/

✅️4-K0s

https://docs.k0sproject.io/v1.25.4+k0s.0/

✅️5- Microk8s

https://microk8s.io/

✅️6- Kind

https://kind.sigs.k8s.io/

No recomiendo para uso en un ambiente de producción donde se requiere una alta disponibilidad y rendimiento; es más que todo para realizar pruebas y aprender todo lo necesario de K8s.

Ahora bien, estamos ansiosos por comenzar y bueno queremos todo en 3...2...1 y aparece K3sup te permite desplegar en tan solo segundos , más rapido que escribir Hello World , si no conocías sobre este proyecto, el mismo es un desarrollo de Alex Ellis, el fundador de Open FaaS e Inlets. Pueden saber más sobre Alex en el siguiente enlace:

https://github.com/alexellis/k3sup

Arquitectura

Conceptual architecture, showing k3sup running locally against any VM such as AWS EC2 or a VPS such as DigitalOcean.

Conceptual architecture

Vamos al fuego creando el clúster

k3supse distribuye como un binario en GO. Puede usar el instalador en MacOS y Linux, o visitar la página de Versiones para descargar el ejecutable para Windows.

Paso 1: Instalamos k3sup

curl -sLS https://get.k3sup.dev | sh
sudo install k3sup /usr/local/bin/

k3sup --help

Si todo sale bien...

$ curl -sLS https://get.k3sup.dev | sh
x86_64
Downloading package https://github.com/alexellis/k3sup/releases/download/0.12.12/k3sup as /home/ec2-user/k3sup
Download complete.
============================================================
  The script was run as a user who is unable to write
  to /usr/local/bin. To complete the installation the
  following commands may need to be run manually.
============================================================
  sudo cp k3sup /usr/local/bin/k3sup
================================================================
  alexellis's work on k3sup needs your support
  https://github.com/sponsors/alexellis
================================================================
No nos devolverá nada, pero podremos correr lo siguiente para saber si k3sup efectivamente se instalo:

$ k3sup --help
Usage:
  k3sup [flags]
  k3sup [command] 
🐳 k3sup needs your support: https://github.com/sponsors/alexellis

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  install     Install k3s on a server via SSH
  join        Install the k3s agent on a remote host and join it to an existing server
  ready       Check if a cluster is ready using kubectl.
  update      Print update instructions
  version     Print the version

Por acá vamos excelente xD

Paso 2:

Ahora bien, en nuestra terminal, vamos a pasar como variable de entorno la dirección IP de nuestro servidor objetivo:

$ export IP=192.168.0.1
$ export USER=root`

Paso 3:

Solo debemos ejecutar:

k3sup install --ip $IP --user $USER

El proceso de creacion del cluster:

$ k3sup install --ip $IP --user $USER
Running: k3sup install
2023/01/10 01:10:17 44.204.142.40
Public IP: 192.168.0.1
[INFO]  Finding release for channel stable
[INFO]  Using v1.25.4+k3s1 as release
[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt
[INFO]  Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/k3s
[INFO]  Verifying binary download
[INFO]  Installing k3s to /usr/local/bin/k3s
[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
[INFO]  Creating /usr/local/bin/crictl symlink to k3s
[INFO]  Creating /usr/local/bin/ctr symlink to k3s
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
[INFO]  systemd: Enabling k3s unit
Created symlink from /etc/systemd/system/multi-user.target.wants/k3s.service to /etc/systemd/system/k3s.service.
[INFO]  systemd: Starting k3s
Result: [INFO]  Finding release for channel stable
[INFO]  Using v1.25.4+k3s1 as release
[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/sha256sum-amd64.txt
[INFO]  Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.25.4+k3s1/k3s
[INFO]  Verifying binary download
[INFO]  Installing k3s to /usr/local/bin/k3s
[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
[INFO]  Creating /usr/local/bin/crictl symlink to k3s
[INFO]  Creating /usr/local/bin/ctr symlink to k3s
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
[INFO]  systemd: Enabling k3s unit
[INFO]  systemd: Starting k3s
 Created symlink from /etc/systemd/system/multi-user.target.wants/k3s.service to /etc/systemd/system/k3s.service.

Saving file to: /home/ec2-user/kubeconfig

# Test your cluster with:
export KUBECONFIG=/home/roxsross/kubeconfig
kubectl config use-context default
kubectl get node -o wide

🐳 k3sup needs your support: https://github.com/sponsors/alexellisll

Paso 4:

Nos conectamos a nuestro servidor via SSH y listo

$ kubectl get nodes
NAME                           STATUS   ROLES                  AGE   VERSION
172-31-8-210.                  Ready    control-plane,master   47s   v1.25.4+k3s1

Super Simple =)

Ahora probemos en AWS , desplegando en una EC2

Requisitos Principales

Instancia AWS EC2, capa gratuita t2.micro
AMI Amazon Linux, Ubuntu, etc.
Key pairs
Install Kubectl https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/
SSH client ó AWS CloudShell

Requisitos adicionales:
Instalación de más nodos usando el agente en la documentación oficial estan los pasos https://github.com/alexellis/k3sup

Security Groups:

22 [SSH]
6443 [ Kubernetes API Server]
2379-2380 [ ETCD server]
10250 [Kubelet health check]
10252 [Kube controller manager]
10255 [ read only kubelet API]
30000-32767 [external applications] Sin embargo, es más probable que exponga aplicaciones externas fuera del clúster a través de balanceadores de carga y restrinja el acceso a estos puertos dentro de su vpc.

Pasos del 1 al 4

Copie la llave ssh en la ubicación 'vi /root/.ssh/id_rsa' en la ec2, exporte la IP e instale k3 usando k3ups

Otra opcion subir la .pem en la ec2 de forma temporal

k3sup install --ip $IP --user $USER --ssh-key llave.pem

Recuerda la IP Publica

`export IP=$(curl icanhazip.com)

k3sup install --ip $IP --user $USER

Solo 46 Segundos.

kubectl run nginx --image nginx:alpine kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80

Visita mi blog https://blog.295devops.com/despliega-un-cluster-de-kubernetes-en-segundos-con-k3sup

Primeros pasos con ArgoCD

Rossana Suarez #RoxsRoss — Sat, 12 Feb 2022 14:05:14 +0000

Introducción

En este artículo hablaremos de una de las herramientas del momento cuando se habla de procesos de integración y despliegue continuo CICD en Kubernetes, ArgoCD. Y es que, en los últimos meses, son muchas las empresas punteras del sector de internet que han declarado públicamente el uso de ArgoCD para desplegar aplicaciones en sus clústers. Puedes ver una lista aquí.

Para empezar, vamos a repasar para qué sirve y hasta dónde llegan las funcionalidades de ArgoCD. Seguidamente, veremos un caso de uso típico de despliegue de aplicaciones usando ArgoCD y las ventajas que nos aporta su implementación. Finalmente, comentaremos las conclusiones que hemos sacado en cuanto a pros y contras, y analizaremos que otras herramientas complementan ArgoCD para optimizar aún más el proceso de integración y despliegue continuo de aplicaciones.

¿Que es ArgoCD?

ArgoCD es una herramienta que nos permite adoptar metodologías GitOps para el despliegue continuo de aplicaciones en clústers de kubernetes.

La principal característica es que ArgoCD sincroniza el estado de las aplicaciones desplegadas con sus respectivos manifiestos declarados en git.

Permitiendo así a los desarrolladores realizar cambios en la aplicación con solo modificar el contenido de git, ya sea con commits a ramas de desarrollo o modificando.

Una vez modificado el código en git, ArgoCD detecta, mediante webhook o comprobación periódica cada 3 minutos, que ha habido cambios en los manifiestos de las aplicaciones. Seguidamente, compara los manifiestos declarados en git con los que hay aplicados en los clústers y actualiza estos últimos hasta sincronizarlos.

Su refinada interfaz de usuario permite visualizar muy bien el contenido, estructura y estado de los clústers ademas que deja manipular los recursos.

¿Permite ArgoCD automatizar todo el proceso de CI/CD de una aplicación?

No, ArgoCD se encarga de desplegar la aplicación una vez ya existe el artefacto en un registro de contenedores, como Dockerhub o ECR. Esto implica que previamente el código de la aplicación ya ha sido testado y «containerizado» en una imagen. Al final de este artículo vamos a hablar sobre qué opciones existen actualmente para llevar a cabo esta tarea.

Como ya hemos explicado, ArgoCD sincroniza el estado de las aplicaciones desplegadas con sus respectivos manifiestos declarados en git. Pero no se refiere al repositorio git del código de la aplicación en sí, sino a otro repositorio separado, como indican las buenas prácticas, que contiene el código de la infraestructura en kubernetes de la aplicación, que puede ser en forma de** helm charts, aplicación kustomize, ksonnet… **

Para explicar mejor los principales beneficios que ofrece ArgoCD veamos un ejemplo de uso.

Usando ArgoCD

En este ejemplo vamos a ver cómo ArgoCD puede desplegar ya sea aplicaciones desarrolladas por terceros, que tiene su propio helm chart mantenido por otra organización, o una propia donde hemos definido el chart nosotros mismos.

Para el ejemplo desplegaremos un stack de monitoring compuesto de Prometheus, Grafana y Thanos mediante sus helm charts.

ArgoCD despliega las aplicaciones mediante un objeto custom llamado Application. Este objeto tiene como atributos un origen y una destinación. El origen puede tener varios formatos, como por ejemplo un helm chart de un repositorio de charts, o un repositorio git que contiene helm charts. La destinación es el cluster al cual será desplegado el contenido del origen. En la configuración del application podemos indicar que ArgoCD mantenga automáticamente sincronizado el estado de los objetos de kubernetes desplegados con la configuración indicada en el origen (charts/git). Esta opción es muy interesante, ya que nos asegura que ArgoCD va a estar pendiente cada pocos minutos de que todo siga en su sitio, por contra, desplegando las aplicaciones directamente con comandos de helm únicamente nos aseguramos la sincronización en el momento de un despliegue.

Ahora que ya hemos explicado que es el objeto Application, para nuestro monitoring-stack, vamos a crear cuatro. *¿Por qué cuatro Applications si solo habrá 3 servicios en el stack? *(Prometheus, Grafana y Thanos)

ArgoCD también nos ofrece la posibilidad de generar grupos de aplicaciones que siguen el concepto de «app of apps pattern» .
Se trata de una ArgoCD application que despliega otras aplicaciones y así recursivamente. En el caso de nuestro monitoring stack, vamos a crear una cuarta aplicación que va a desplegar las otras 3 restantes, la aplicación padre la vamos a llamar «monitoring-stack».

Para crear una aplicación podemos definir un manifiesto ArgoCD Application, como se indica en esta página de la documentación. También podemos mediante línea de comandos. Pero ArgoCD tiene una genial UI que permite crear aplicaciones manualmente también, puede ver cómo aquí.

La aplicación «monitoring-stack» apuntará su origen a un repositorio git con un Helm chart. Este chart contendrá los manifiestos de las otras tres aplicaciones en el directorio «templates» en formato yaml. Estos archivos son definiciones de objetos Application que apuntan al pertinente Helm chart oficial de cada servicio. Mediante los «values files», podremos desplegar diferentes versiones en entornos distintos.

Repositorio git que contiene un Helm chart de monitoring-stack. Este consta de 3 aplicaciones definidas en el directorio monitoring-stack/templates/

Una vez definidas las templates del chart «monitoring-stack», vamos a crear la ArgoCD Application, y en source vamos a apuntar hacia el repositorio que lo contiene. ArgoCD va a detectar que se trata de un helm chart y podremos indicar el path del values file concreto, por ejemplo «prod-values.yaml».

Al finalizar la configuración manual de la aplicación, en la interfaz de usuario veremos como se representan todos los objetos generados, organizados de forma jerárquica.

La aplicación monitoring-stack crea las tres aplicaciones definidas en el directorio templates del chart.

La aplicación grafana ha desplegado el helm chart, mediante la UI podemos ver todos los recursos en funcionamiento. También nos permite interactuar con estos, por ejemplo podemos borrar un pod y ver cómo el deployment despliega otro automáticamente.

Al estar las aplicaciones sincronizadas con nuestro repositorio, y los charts parametrizados con templates y values. Para desplegar una nueva versión de cualquiera de nuestras aplicaciones solo tendremos que modificar el archivo values mediante commits de git.
ArgoCD se encargará de detectar los cambios en el repositorio y aplicarlos en el clúster de kubernetes mediante un despliegue rolling update.

versiones del chart definidas en el archivo prod_values.yaml

Como apunte, usando ArgoCD Image Updater nos podemos ahorrar hacer este último paso manualmente, o incluso tener que desarrollar una pipeline compleja para actualizar el fichero values.yaml en git cuando queremos desplegar la nueva imagen.

Esta herramienta consulta periódicamente los últimos tags en nuestro repositorio de imágenes buscando nuevos artefactos para desplegar. De esta forma, una vez ha encontrado uno nuevo, se encarga de automatizar el proceso de despliegue editando la configuración de git con el nombre del nuevo tag.
Hace falta mencionar que aún no hay una versión estable de ArgoCD Image Updater, pero se la espera pronto.

En este ejemplo hemos creado una aplicación que apunta a un repositorio que crea aplicaciones las cuales apuntan a helm charts oficiales, sin embargo este bucle jerárquico se puede extender mucho mas, siguiendo el «app of apps pattern».

Otra característica interesante de ArgoCD es que nos permite desplegar aplicaciones en distintos clústers. Hay varias maneras de hacerlo, no obstante la más directa es mediante el recurso Application Set.

En su manifiesto podemos especificar una lista de clusters donde desplegar simultáneamente con distintos paths del repositorio. Ya que en nuestro repositorio podemos especificar diferentes versiones para cada clúster.

La relativa facilidad de instalación que tiene ArgoCD supone otro punto positivo a tener en cuenta, aquí puedes consultar los pasos.

Automatización de todo el proceso CICD con Argo

En el caso de querer ir un paso más allá y automatizar todo el proceso de CICD en kubernetes, podemos complementar ArgoCD con el resto de herramientas que presenta el proyecto Argo.

Combinando Argo Events, Argo Workflows, ArgoCD y Argo Rollouts es posible una mayor automatización siguiendo las mejores prácticas en los estándares actuales de integración continua.

Victor Farcic lo explica de manera muy coherente en este video.

Como solución a la complejidad añadida que supone instalar y manejar todas estas herramientas de Argo project, ya han salido al mercado algunas aplicaciones que engloban todo este stack y nos permiten configurar los pipelines para la integración y despliegue des de una capa de mas alto nivel mas simplificada. A continuación mencionamos un par de ellas, aun que en este post no vamos a analizar las funcionalidades particulares.

Devtron es una herramienta open source que instala por debajo todo este paquete de Argo y otras herramientas y promete permitirnos automatizar todo el proceso CICD por completo des de la interfaz gráfica. Devtron simplifica bastante la configuración, ya que interactuamos con las herramientas internas des de una capa de alto nivel. Aunque después de probarlo, no creemos que la herramienta tenga la suficiente madurez como para ser implementada en un entorno productivo, de momento.

Similar al approach de Devtron, Codefresh engloba todas las aplicaciones del stack de Argo para automatizar toda la integración y despliegue. Pero aparte de que la herramienta aún se encuentra en early-access, una gran diferencia es que el acceso a la herramienta será en formato SaaS. Como podemos ver en el apartado de pricing, la opción de automatización completa será de pago y el precio no se menciona en la web.

Conclusiones

ArgoCD es una herramienta muy útil para automatizar el proceso de deploy mediante buenas prácticas GitOps. Gracias a su implementación, los developers pueden probar las nuevas versiones de las aplicaciones más rápidamente y desplegar en producción de forma segura una vez finalizados las pruebas.

Además, gracias a la función de auto-sync y su bonita interfaz, ArgoCD nos permite tener controlado en todo momento el estado de las aplicaciones y sus recursos desplegados en Kubernetes. Combinado con las demás herramientas del proyecto Argo podemos automatizar todo el proceso de CICD (y otras muchas utilidades fuera del scope de este post) siguiendo buenas prácticas para los estándares actuales.

Como punto negativo, usar ArgoCD introducirá una capa extra de complejidad a nuestra configuración, ya que dispone de muchas opciones distintas, introduce «custom objects» y conceptos a los cuales no estamos familiarizados aún. Puede ser «overkill» si tenemos un clúster muy pequeño con solo un puñado de aplicaciones.

Bonus Track

CodeFresh lanzo un curso con certificacion totalmente gratuito sobre GitOps y ArgoCD
link

Follow https://github.com/roxsross
Linkedin https://www.linkedin.com/in/roxsross/

Mejorando la seguridad con DevOps

Rossana Suarez #RoxsRoss — Fri, 04 Feb 2022 15:36:14 +0000

Con CI/CD, las organizaciones pueden satisfacer rápidamente las necesidades más actuales del negocio a medida que evolucionan rápidamente, pero sin un enfoque continuo de la seguridad, una vez más, la seguridad está aislada. Las organizaciones deben ser capaces de adaptar sus requisitos de seguridad a los cambios tanto internos (cambio de bases de datos, diferentes versiones de software, etc.) como externos (requisitos de cumplimiento, panorama cambiante de amenazas, etc.).

Necesitamos llevar CI/CD un paso más allá y también tener la seguridad integrada continuamente.

Por extensión, la seguridad continua (CI/CD/CS) cumple con los estándares de seguridad más actuales para el negocio, teniendo en cuenta los cambios internos y externos en todo el SDLC.

Para adoptar efectivamente un CI/CD/CS, las organizaciones deben centrarse en estos principios clave:

No existe un código perfecto, por lo tanto, no existe una seguridad perfecta:

La buena seguridad de las aplicaciones gestiona el riesgo cibernético de acuerdo con la estrategia comercial general. Cuando tiene la capacidad de aceptar el riesgo dentro de la tolerancia al riesgo de los negocios, sabe los momentos correctos para detenerse y los momentos correctos para continuar porque existen otros controles. No dejes que la perfección sea enemiga del éxito.

Seguridad de aplicaciones desde el día uno:

DevOps no se trata de moverse rápido y romper cosas, se trata de moverse de manera eficiente y arreglar las cosas en el momento adecuado. Entregue la información de seguridad de la aplicación correcta en el momento adecuado a la parte interesada responsable de ejecutarla. Esto asegura una mejor colaboración para que las partes interesadas sepan dónde, cuándo y con quién dirigir su atención.

Micro-feedback en tiempo real:

Aproveche la orquestación para obtener retroalimentación en tiempo real sobre el cumplimiento de las políticas antes de que cree cuellos de botella en el futuro. Esto le permite responder a los cambios tanto internos como externos lo más rápido posible, creando un ciclo iterativo de información para la toma de decisiones en el futuro.

Al administrar continuamente las prácticas de seguridad, las políticas y la deuda en las canalizaciones de CI/CD existentes, este enfoque permite implementar un programa de seguridad de aplicaciones escalable en cualquier SDLC para que pueda evolucionar continuamente para estar siempre al mismo nivel que el negocio actual.

Terraform, todo lo que necesitas saber para comenzar a usar nuestros Módulos

Rossana Suarez #RoxsRoss — Thu, 03 Feb 2022 23:10:53 +0000

Los módulos en Terraform son una colección de recursos que se pueden vincular o simplemente crear individualmente. Cuando llamamos a un módulo, estamos llamando a un archivo con una serie de recursos y algunos parámetros, los cuales necesitamos especificar o bien en el propio recurso o en otro archivo que almacene nuestras variables.

¿Por qué usar Terraform?

Es una herramienta muy útil para desarrollar, cambiar y tener una versión de nuestra infraestructura de manera eficiente y segura.
Es una herramienta que permite definir infraestructura como código y habilita cambiar y hacer un seguimiento de la infraestructura con facilidad.
Es independiente de la plataforma o ‘cloud agnostic’ y permite trabajar con múltiples proveedores cloud.

¿Qué necesitamos para este laboratorio?

Terraform instalado. En este caso, ejecutamos la v.1.0.0
En nuestro caso, utilizamos AWS como nuestro proveedor de servicios en la nube, por lo que necesitamos un usuario con acceso mediante programación.
Tu editor de código preferido.

Por lo general, primero deberíamos configurar un módulo Terraform para el "backend" con nuestros parámetros requeridos o simplemente obtener algún módulo oficial de la red. En nuestro caso, estamos usando un módulo propio con un Bucket S3 Y DynamonDB , por lo tanto, especificamos qué parámetros queremos en nuestro módulo.

¿Qué es un backend? ¿Y el tfstate?
El tfstate es el fichero donde se guardan los datos con los recursos que hemos ido creando con nuestro código en Terraform. El backend es donde decidimos guardar ese archivo/s.

Este módulo de Terraform implementa los recursos necesarios para almacenar el estado de Terraform en AWS.
** Esto incluye**

Amazon S3 Bucket
DynamoDB Table

¡Empecemos!

Creamos una carpeta modules y luego terraform-aws-s3-backend

└── modules
    └── terraform-aws-s3-backend

Vamos a definir las variables que necesitamos, en este caso necesitamos el nombre de buckets3 y el de la dynamondb

variables.tf

variable "s3_bucket" {
  type        = string
  description = <<-EOF
  Name of the Amazon S3 bucket to store Terraform state.
  EOF
}

variable "dynamodb_table" {
  type        = string
  description = <<-EOF
  Name of the DynamoDB table to store Terraform state lock.
  EOF
}

ahora vamos a definir nuestros recursos para ser usado como backend

main.tf

# -----------------------------------------------------------------------------
# AMAZON S3 BUCKET y DYNAMODB TABLE PARA TERRAFORM STATE
# Este módulo de Terraform despliega los recursos necesarios para almacenar Los estados de Terraform en AWS
# estado en AWS.
# INCLUYE:
#   * Amazon S3 Bucket
#   * DynamoDB Table
# -----------------------------------------------------------------------------

terraform {
  required_version = ">= 1.0.0"
}

# -----------------------------------------------------------------------------
# S3 BUCKET
# 
# -----------------------------------------------------------------------------
resource "aws_s3_bucket" "s3_bucket" {
  bucket = var.s3_bucket

  # El propietario obtiene FULL_CONTROL. Nadie más tiene derechos de acceso(default).
  acl = "private"

  versioning {
    enabled = true
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
#Prevenimos explícitamente la destrucción usando terraform. true|false
  lifecycle {
    prevent_destroy = true
  }
}

# -----------------------------------------------------------------------------
# DYNAMODB TABLE
# 
# -----------------------------------------------------------------------------
resource "aws_dynamodb_table" "dynamodb_table" {
  name = var.dynamodb_table
  billing_mode   = "PROVISIONED"
  read_capacity  = 1
  write_capacity = 1
  hash_key = "LockID"
  attribute {
    name = "LockID"
    type = "S"
  }
}

y por supuesto la salida.

output.tf

# -----------------------------------------------------------------------------
# OUTPUTS
# -----------------------------------------------------------------------------
output "s3_bucket" {
  value       = aws_s3_bucket.s3_bucket.id
  description = "El nombre del S3 bucket"
}

output "dynamodb_table" {
  value       = aws_dynamodb_table.dynamodb_table.id
  description = "El nombre del DynamoDB table"
}

Ahora como probamos nuestro modulo

creamos una carpeta por ejemplo example para hacer la llamada, cabe destacar que podemos almacenar todos nuestros módulos y poder hacer las distintas llamadas, muchas cosas por hacer.

dentro del directorio example
creamos el archivo main.tf

# -----------------------------------------------------------------------------
# AMAZON S3 BUCKET - DYNAMODB TABLE TERRAFORM STATE
# -----------------------------------------------------------------------------
provider "aws" {
  region = "us-east-1"
}

#Acá un punto clave le estamos dando la ruta donde esta nuestro modulo, también podemos llamar a un repo donde podría servir como banco de módulos

module "s3_backend" {
  source         = "../../terraform-aws-s3-backend"
  s3_bucket      = "tf-roxsross-s3-bucket"
  dynamodb_table = "tf-roxsross-dynamodb-table"
}

y ademas nuestra salida output.tf

# -----------------------------------------------------------------------------
# OUTPUTS
# -----------------------------------------------------------------------------
output "s3_bucket" {
  value       = module.s3_backend.s3_bucket
  description = <<-EOF
  el nombre del S3 bucket para almacenar el estado de Terraform
  EOF
}

output "dynamodb_table" {
  value       = module.s3_backend.dynamodb_table
  description = <<-EOF
  el nombre de la DynamoDB table para almacenar el estado de Terraform
  EOF
}

.
└── modules
    └── terraform-aws-s3-backend
        ├── example
        │   ├── main.tf
        │   └── output.tf
        ├── main.tf
        ├── output.tf
        └── variables.tf

Y por último, desplegar nuestro módulo con los comandos terraform init, terraform plan y terraform apply.

y no te olvides del terraform validate , para validar que todo este okey

Terraform plan

terraform plan -out plan.out

y Aplicamos!!

terraform apply "plan.out"

En este post, hemos visto cómo desplegar un Bucket S3/dynamodb “backend” Recuerda visitar la documentación oficial de Terraform para seguir aprendiendo sobre los módulos, recursos y sus parámetros.

y estamos en AWS

*y un bonus track *

Recuerden utilizar herramientas para escanear vulnerabilidades en nuestros módulos.

voy a usar https://snyk.io/

con la CLI

snyk iac Find security issues in Infrastructure as Code files.

snyk iac test terraform-aws-s3-backend/

Repositorio Github ->>>> https://github.com/roxsross/modules-roxsross-tf

Diseño de Arquitectura Cost-Efficient en la Nube

Rossana Suarez #RoxsRoss — Thu, 30 Dec 2021 17:12:19 +0000

Hoy en día, la mayoría de los datacenters quedaron en el pasado, y la nube se ha hecho cargo en gran medida con la promesa de escalabilidad, flexibilidad y rentabilidad.A pesar de estas promesas, la nube a menudo no alcanza estos ideales. ¿Por qué?

Porque administrar la nube es difícil, especialmente cuando se trata de administrar sus costos. No hay ahorros automáticos en el momento en que se registra en AWS o cualquier otro proveedor de la nube. En cambio, lograr ahorros en la nube requiere mucha planificación de capacidad, análisis cuidadoso, monitoreo consistente, pronósticos precisos y ajustes interminables; es suficiente trabajo para hacer girar la cabeza a cualquiera.

Pero las recompensas hacen que valga la pena el esfuerzo. Si administra su nube correctamente, ofrece enormes ahorros en comparación con los entornos locales. Sin embargo, pasar a la nube sin antes implementar una estrategia de costos puede costarle millones a su organización a medida que escala a largo plazo.

Entonces, ¿qué pasos se debe seguir para asegurarse de maximizar sus ahorros en la nube?

A continuación, se incluyen algunas recomendaciones comunes que puede comenzar a implementar, o dejar de hacer, ahora.

Migrar a la Nube

La migración a la nube es el primer paso y el más complejo. Entonces, antes de comenzar, tenga en cuenta lo siguiente:

Hacer: analizar su entorno antes de la migración

Seamos realistas: si tiene un entorno local desorganizado y sobreaprovisionado, tendrá un entorno de nube desorganizado y sobreaprovisionado. A menos, por supuesto, que lo limpies antes de la gran migración.

En el lado positivo, limpiar su entorno actual y familiar es menos abrumador que hacer la limpieza una vez que se migre al nuevo y desconocido entorno de nube. Por lo tanto, es fundamental analizar su entorno actual antes de su migración a la nube.

Comience por desmantelar todos los activos que no se estén utilizando actualmente. Por ejemplo, puede tener una máquina virtual (VM) que se aprovisionó para un proyecto en particular y no se apagó una vez finalizado ese proyecto. Como resultado, tendría una aplicación en ejecución que ya no es necesaria. Identificar y eliminar estos recursos ahora reducirá los costos futuros de la nube y aliviará a los ingenieros de futuros dolores de cabeza.

Hacer: crear un modelo para su arquitectura en la nube

A continuación, debe rediseñar su listado de aplicaciones. No se preocupe, esta tarea no es tan aterradora como parece. Deberá crear una lista de la infraestructura que está utilizando ahora y encontrar su infraestructura correspondiente en la nube. Digamos, por ejemplo, que está utilizando varios servidores dedicados para la cola de mensajes. Si se migra a AWS, deberá identificar tipos de instancias similares en AWS antes de su migración a la nube.

No: siga el enfoque de "levantar y cambiar"

Puede ser tentador, pero hagas lo que hagas, evita el enfoque de "levantar y cambiar". Ciertamente, existen formas de optimizar su entorno actual, por lo que simplemente mover exactamente lo que tiene a la nube es una oportunidad perdida para reorganizar, reestructurar y optimizar el rendimiento y los costos.

Por ejemplo, puede estar ejecutando máquinas virtuales que no se están utilizando, haciendo copias de seguridad de servidores de desarrollo no utilizados o almacenando datos que se pueden asignar a una clase de almacenamiento de archivo de bajo costo. Asegúrese de reajustar su arquitectura para que se ajuste a la nube, no al revés.

Gobernancia

La conclusión es que alguien debe ser responsable de administrar los costos de la nube. Dependiendo del tamaño de su empresa, puede ser un equipo o un individuo, pero debe hacerse más temprano que tarde.

Hacer: asegurarse de que el gasto en la nube sea administrado por una persona o equipo específico

Cumplir con un presupuesto en la nube es más fácil de decir que de hacer, pero si delega esta tarea a un equipo o individuo específico, será su principal prioridad asegurarse de que su empresa se mantenga en el objetivo. Serán responsables de manejar los presupuestos de la nube, establecer quién puede y quién no puede proporcionar recursos y monitorear el uso.

Si no logra establecer la gobernanza, corre el riesgo de que muchas personas suministren recursos sin responsabilidad alguna, lo que se traduce en un gasto excesivo significativo y mucho caos.

No: suponga que la gobernanza es solo para grandes organizaciones

¿Cree que su empresa es demasiado pequeña para la gobernanza?

Piensa otra vez.

Al menos una persona siempre debe ser responsable de monitorear su gasto en la nube y asegurarse de que se mantenga en línea con el presupuesto asignado. Esta persona trabajará mano a mano con finanzas para crear presupuestos, monitorear el uso, crear alertas de facturación y más.

Seguridad en la Nube

Si está migrando a la nube sin pensar en la seguridad, está cometiendo un gran error. Se estima que el ciberdelito costará al mundo más de $ 10,5 billones para 2025 . Peor aún, según un estudio reciente de Verizon, las violaciones de seguridad en la nube han superado a sus contrapartes locales por primera vez.

Por lo tanto, no hace falta decir que se debe priorizar la seguridad al pasar a la nube. A continuación, se ofrecen algunos consejos para comenzar.

Qué hacer: Desarrollar un plan de seguridad en la nube de varios niveles y capas

Su estrategia de seguridad en la nube debe proteger tanto sus datos como sus activos de TI en caso de un ciberataque, al mismo tiempo que cumple con los estándares y regulaciones específicas de su industria.

Algunas estrategias de seguridad en la nube incluyen:

Construyendo su solución con un marco bien diseñado

Uso de soluciones como detección de amenazas, parches automatizados o auditoría de seguridad
Conexión de su red local a la nube mediante una puerta de enlace de tránsito o tecnologías similares
Crear suficientes reglas de firewall para sistemas tradicionales y aplicaciones web.

No: confíe exclusivamente en los controles de seguridad de su proveedor de nube

Si bien muchos proveedores de la nube ofrecen excelentes soluciones de seguridad, confiar exclusivamente en ellos no lo ayudará a cubrir sus bases. AWS se refiere regularmente al modelo de responsabilidad compartida , que establece que AWS cubre la infraestructura, pero el usuario debe proteger sus propias aplicaciones.

Programación de sus instancias

Cuanto más tiempo ejecute sus servidores, mayor será su factura. Y, desafortunadamente para nosotros, crear una nueva máquina virtual en la nube se ha vuelto tan fácil que muchos olvidan apagarlas cuando ya no están en uso. Esto da como resultado costos en la nube que son hasta un 66% más altos de lo necesario.

Por lo tanto, si está buscando reducir los costos de la nube , tenga en cuenta lo siguiente al programar sus instancias:

Hacer: programar instancias automáticamente

Seamos realistas, es fácil olvidarse de cerrar instancias fuera de horario. De hecho, es tan fácil que nos puede pasar incluso a los mejores. La programación automática de instancias, por otro lado, evita errores humanos al tiempo que simplifica el proceso de apagado.

El programador de instancias de Amazon de AWS o la función Start / Stop de Azure facilitan el cierre de instancias de entornos que no son de producción durante las "horas de inactividad" y las vuelven a activar una vez que se necesitan. Además de estas herramientas, debería considerar la posibilidad de implementar alertas para que se le notifique si algo sale mal en el proceso de programación.

Sí: aproveche el escalado automático de AWS

El escalado automático de AWS permite aprovechar al máximo la elasticidad de la nube. La tecnología monitorea continuamente las necesidades de capacidad de su aplicación y ajusta automáticamente los recursos para adaptarse a su uso actual. Como resultado, no tiene que crear una máquina virtual grande para su carga de trabajo. En su lugar, puede comenzar con un servidor de baja especificación y agregarlo a un grupo de escalado automático. Cuando aumente la demanda, se agregarán más nodos a su flota para adaptarse a la escala. Del mismo modo, cuando la demanda disminuye, los nodos adicionales se reducirán.

Esto ayuda a optimizar tanto el rendimiento como los costos para que nunca pague por los recursos que no usa y siempre tenga la cantidad correcta de instancias para ejecutar sus aplicaciones.

No: permita que sus máquinas virtuales se ejecuten continuamente

Esto puede parecer obvio, pero como mencionamos anteriormente, muchos olvidan apagar las máquinas virtuales cuando no son necesarias. Por ejemplo, de 9 a. M. A 5 p. M. De lunes a viernes pueden ser sus horas pico. Esto significa que probablemente no necesitará que ciertas máquinas virtuales se ejecuten los sábados o a las 3 a. M., Entonces, ¿por qué pagar por ellas? En su lugar, apague las máquinas virtuales durante las "horas de inactividad" para asegurarse de maximizar sus ahorros.

Etiquetar sus recursos

No hay forma de evitarlo: etiquetar recursos es una parte esencial para comprender sus patrones de uso y optimizar los costos de la nube. Las etiquetas de activos son etiquetas de metadatos que se pueden atribuir a recursos individuales en su flota en la nube para rastrear a qué aplicación pertenece. Por lo general, puede asignar hasta 50 etiquetas por recurso, y se pueden organizar y nombrar según sus necesidades.

Al etiquetar activos, asegúrese de tener en cuenta lo siguiente:

Qué hacer: implementar una estrategia de etiquetado al principio de su viaje a la nube

Nunca es demasiado pronto para empezar a etiquetar activos. De hecho, cuanto más lo posponga, más difícil se volverá. Una vez que aumente su gasto y uso, lo que inevitablemente sucederá, necesitará tener un sistema de etiquetado para determinar qué equipo es responsable de cada activo (para que pueda hacer que evalúen los recursos y costos), desactivar los recursos innecesarios y más .

Las etiquetas son extremadamente útiles en muchos escenarios del mundo real. Por ejemplo, si no está utilizando una aplicación específica, puede buscar la etiqueta "aplicación" con un valor del nombre de la aplicación. A continuación, verá todos los recursos relacionados con esa aplicación, para que pueda eliminarlos fácilmente.

Además, las etiquetas se pueden utilizar para hacer cumplir los presupuestos y evitar gastos excesivos. Simplemente establezca un límite de presupuesto en su etiqueta y configure alertas para notificar cuando se esté acercando a ese límite.

No debe embarcarse en la migración a la nube antes de etiquetar recursos

El etiquetado es simple si lo hace al principio cuando su entorno no es tan complejo. Pero es insoportablemente difícil una vez que su entorno es más maduro. Por lo tanto, si se está mudando a la nube, asegúrese de comenzar a etiquetar de antemano para que no se arrepienta de nada.

Qué hacer: usar instancias reservadas y planes de ahorro

Si está en AWS, el uso de instancias reservadas (RI) y planes de ahorro puede ahorrarle hasta un 72% sobre los precios bajo demanda del gigante de la nube. El problema es que debe comprometerse a comprar instancias reservadas con uno o tres años de anticipación, lo que significa que deberá predecir sus necesidades de uso con anticipación. A pesar de este desafío, las instancias reservadas ofrecen enormes ahorros para quienes las utilizan con prudencia.

No: compre instancias reservadas o planes de ahorro sin desarrollar una estrategia

Al utilizar las instancias reservadas, es fundamental desarrollar una estrategia para garantizar que se maximicen sus ahorros. A menudo, las personas cometen el error de comprar muchas instancias reservadas, que no se utilizan. Esto se traduce en ahorros iniciales, pero sin retorno. Asegúrese de elaborar un plan sobre cómo manejar la capacidad reservada. Venderlos en el mercado de AWS es un buen lugar para comenzar.

Nos trasladamos a la nube con la promesa de mayor flexibilidad y menores costos. Pero para hacer realidad esa promesa, no podemos esperar que la nube o nuestro proveedor de nube hagan todo el trabajo por nosotros. Desafortunadamente, los ahorros en la nube no son automáticos.

Es por eso que la creación de una estrategia que cubra los costos, la seguridad y otros aspectos críticos de la migración a la nube debe ser su prioridad número uno. Incluso si ha estado utilizando la nube durante años, debe continuar reevaluando su estrategia de costos de la nube para asegurarse de que esté completamente optimizada. Comience por identificar las prácticas que resultan en el desperdicio de la nube y crear un plan de juego para evitar que suceda.

Tenga en cuenta que siempre están surgiendo nuevas tecnologías, así que asegúrese de estar al tanto de cualquier cambio en la industria que pueda afectar su estrategia de costos en la nube.

@roxsross

Solo el 30% de las empresas implementan DevSecOps

Rossana Suarez #RoxsRoss — Wed, 29 Dec 2021 19:21:09 +0000

Con la presión de lanzar más rápidamente, la seguridad se está moviendo hacia la izquierda dentro de la línea de desarrollo continuo en la mayoría de las organizaciones. Este imperativo está aumentando con el aumento de los ciberataques. Sin embargo, tanto la falta de capacitación como la escasa visibilidad están estancando muchas implementaciones de DevSecOps, según un estudio reciente de CSA.

DevSecOps es todavía una práctica relativamente nueva y aún no ha alcanzado la madurez en la mayoría de las organizaciones. Aunque casi todas las empresas están en camino, solo el 30% de los profesionales de seguridad dicen que implementan completamente DevSecOps a la fecha de hoy. Eso deja a la mayoría de las organizaciones en algún estado de ideación y planificación de DevSecOps.

CSA publicó recientemente su informe Secure DevOps and Misconfigurations 2021 que fue encargado por Trend Micro. El informe encontró que las configuraciones incorrectas comúnmente surgen de la configuración de seguridad. La falta de orientación interna y la accesibilidad de los recursos de seguridad también dificultan la madurez de DevSecOps.

A continuación,

algunas conclusiones importantes del informe para ver cómo pueden informar a las organizaciones a medida que avanzan para implementar DevSecOps.

Estado de adopción de DevSecOps
DevSecOps se trata de aumentar la seguridad en torno a una implementación rápida. Literalmente, coloca la seguridad en DevOps al cambiar la automatización de la seguridad a la izquierda y eliminar el límite entre DevOps y los equipos de seguridad de TI .

Si bien la mayoría de los ingenieros se dan cuenta de los beneficios de DevSecOps, integrar DevSecOps en cada organización es muy diferente. Si bien un impresionante 90% de las organizaciones se encuentra en alguna fase rumbo hacia DevSecOps, sólo el 30% está implementando DevSecOps mientras que el 24% está en la fase de planificación, el 18% está diseñando y el 18% todavía está refinando su estrategia DevSecOps. Un poco más de uno de cada diez profesionales de la seguridad dice que su equipo no tiene planes de invertir en DevSecOps.

Mirando hacia el futuro, el 42% dice que implementará DevSecOps completo en los próximos 12 meses. Pero debido a su estado incipiente actual, las configuraciones incorrectas todavía se están logrando. La razón principal citada para estas configuraciones erróneas fue defectuosa o falta de orientación interna (33%).

Muchos profesionales dicen que simplemente no hay suficiente capacitación, soporte o conocimiento interno sobre vulnerabilidades y configuraciones incorrectas. Otras razones principales de las configuraciones incorrectas incluyen configuraciones predeterminadas inseguras (18%) y negligencia (16%).

Fuera de las configuraciones incorrectas, los grupos también informan problemas con la identidad, la autorización y el acceso. Asegurar los privilegios correctos es vital para evitar ataques de escalada, que son un problema frecuente. Entre 2019 y 2020, el 80% de las empresas experimentaron una violación de datos de algún tipo, muchas de las cuales se debieron a controles de acceso mal configurados. OWASP también informó que la autorización rota es una de las principales vulnerabilidades para los puntos finales de API web de alto tráfico.

Prácticas comunes de mitigación de amenazas
Para mitigar estas amenazas, los equipos de desarrollo y seguridad deben mantener las mejores prácticas, pero ciertos problemas evitan que surjan DevSecOps. Por un lado, el 60% de los profesionales de seguridad dicen que su principal desafío es la visibilidad insuficiente de la seguridad o las brechas de cumplimiento (este es, con mucho, el desafío más común) y el 11% también menciona la incorporación inconsistente de cuentas en la nube. Finalmente, el 10% dice que la arquitectura es lenta y / o insuficiente los detiene.

Una forma de mitigar las amenazas es introducir revisiones de seguridad de rutina con más frecuencia. Sin embargo, es difícil establecer un punto de referencia definitivo aquí, ya que la frecuencia con la que las organizaciones revisan su infraestructura de nube en busca de vulnerabilidades o configuraciones incorrectas varía ampliamente. Actualmente, el 22% realiza dichas revisiones de seguridad diariamente, el 22% mensualmente, el 18% semanalmente y el 23% trimestralmente, según la encuesta. Es probable que esta tasa aumente a medida que DevSecOps se vuelva más común y automatizado dentro del ciclo de vida del desarrollo.

Mantenerse actualizado con los marcos de seguridad modernos es otra faceta que afecta la adopción de DevSecOps; y las organizaciones tienden a seguir múltiples marcos para informar su estrategia de seguridad. Más de las tres cuartas partes (78%) siguen las pautas del Instituto Nacional de Estándares y Tecnología (NIST), el 67% sigue los puntos de referencia del Centro de Seguridad de Internet (CIS), el 66% sigue la Alianza de Seguridad en la Nube (CSA), el 54% sigue la Organización Internacional para la estandarización (ISO) y el 44% dice que sigue las recomendaciones de seguridad de Amazon Web Services (AWS).

Por ejemplo, NIST, el organismo de establecimiento de estándares operado por el gobierno, estableció recientemente pautas de seguridad cibernética que recomendaban el uso de una malla de servicio y confianza cero en todos los departamentos. Estas pautas de seguridad se pueden considerar como puntos de referencia arquitectónicos, especialmente para industrias grandes y altamente reguladas .

Tipos de formación de DevSecOps
Finalmente, invertir en recursos y capacitación es otra forma de aumentar la conciencia de DevSecOps. Solo la mitad de los encuestados informaron que sus recursos de mejores prácticas de DevSecOps eran moderadamente accesibles; por lo tanto, los líderes tienen la responsabilidad de democratizar dicho conocimiento dentro de su organización.

La mayoría (81%) de los encuestados citó los artículos y la capacitación online como su forma principal de aprender sobre las herramientas de seguridad en la nube. Los talleres, conferencias y seminarios web siguen de cerca. Las organizaciones también adoptan muchos métodos internos de intercambio de conocimientos en respuesta a incidentes. Un 85% dijo que lleva a cabo un entrenamiento de concientización seguido de ejercicios (52%), simulaciones de ataque (45%) y entrenamiento de protocolo o marco de respuesta (37%).

Futuros DevSecOps en la nube
Parece que la mayoría de los equipos todavía están formulando su estrategia DevSecOps. Pero mirando hacia el futuro, el 42% dice que implementará DevSecOps completo en los próximos 12 meses. Al mismo tiempo, se proyecta más tracción en la nube en toda la industria.

En este momento, el 40% de las organizaciones tienen entre el 41% y el 99% de sus cargas de trabajo en la nube pública. Y el 55% de las organizaciones tendrán entre el 41% y el 99% de sus cargas de trabajo en la nube pública durante el próximo año. El tipo de cargas de trabajo probablemente también evolucionará en el próximo año, a medida que más organizaciones se trasladen a plataformas de contenedores , función como servicio y otras capacidades sin servidor. Sin duda, para aprovechar plenamente los beneficios que prometen estas nuevas tecnologías, las organizaciones deben responder a una nueva clase de vulnerabilidades nativas de la nube .

Sobre el informe
Cloud Security Alliance (CSA) es una organización sin fines de lucro con la misión de promover ampliamente las mejores prácticas para garantizar la ciberseguridad en la computación en la nube y las tecnologías de TI. La encuesta Secure DevOps and Misconfigurations se realizó desde julio de 2021 hasta septiembre de 2021 y recopiló más de 900 respuestas de un grupo global de profesionales de seguridad de TI que trabajan en varios sectores y tamaños de organización. Para obtener una copia completa del informe, puede intercambiar información personal por una descarga en PDF aquí . [https://cloudsecurityalliance.org/artifacts/secure-devops-and-misconfigurations-survey-report/)]

5 razones por las que Go en DevOps es el Futuro.

Rossana Suarez #RoxsRoss — Wed, 29 Dec 2021 12:51:08 +0000

5 razones por las que Go en DevOps es el Futuro.

Golang o Go (Go Programming Language) es un lenguaje de programación open source bastante reciente, creado en 2007 por los programadores de Google Ken Thompson y Rob Pike, quienes ya contaban con una reconocida trayectoria por la creación de los lenguajes B y Limbo, respectivamente., el lenguaje fue diseñado por y para personas que escriben, leen, depuran y mantienen grandes sistemas de software.

Go es un excelente lenguaje de programación para la ingeniería de grandes proyectos de software. Algunas de las tecnologías de contenedores más populares utilizadas en DevOps como Docker y Kubernetes están escritas en Go.

También es amado por la comunidad de desarrolladores. Según la encuesta de desarrolladores de 2021 realizada por Stackoverflow, Go se encuentra en la quinta posición en la lista de los lenguajes de programación más queridos y en la tercera posición en la lista de los lenguajes más buscados para aprender.

Entonces, ¿cuáles son algunas de las características del lenguaje de programación Go que lo hacen ideal para DevOps?

Los programas Go están vinculados
Cuando se compila un programa Go, todo se incluye como un único binario y no hay dependencias externas que deban instalarse en la máquina de destino en la que está previsto que se ejecute el programa Go. Y esto hace que la implementación de los programas Go sea realmente fácil.

Creación e implementación de programas Go
Aunque Go es un lenguaje compilado, se compila directamente en código de máquina a diferencia de la programación orientada a objetos que se requiere para Java. Go fue diseñado para ser extremadamente rápido. Aquí hay un pequeño juego de referencia que compara Go vs Python .

Go es independiente de la plataforma
Los ejecutables binarios de los programas Go se pueden producir para cualquier plataforma como Windows, Linux y macOS. Para que un binario sea compatible con los diferentes sistemas operativos, todo lo que se necesita es establecer dos variables de entorno: $GOOS, $GOARCH.

Lenguaje extremadamente eficaz
El programa Go tiene tiempos de compilación rápidos y tiempos de ejecución rápidos con un menor uso de recursos como CPU y memoria, especialmente en comparación con un lenguaje como Python. Como el compilador falla en la ejecución si hay importaciones no utilizadas, el tiempo de compilación es corto. Y como el código se compila en código de máquina, también se ejecuta rápidamente.

Disponibilidad de bibliotecas Estándar para Go
A diferencia de Python, que a menudo requiere el uso de bibliotecas de terceros para implementar un programa de Python en particular, el lenguaje de programación Go tiene una biblioteca estándar que incluye muchas funciones integradas que necesitará como ingeniero de DevOps.
Esto incluye funciones como procesamiento de archivos, servicios web HTTP, procesamiento JSON, soporte nativo para simultaneidad y paralelismo, así como módulos de prueba integrados.

Recomiendo este curso de Nana Janashia "Golang Tutorial for Beginners | Full Go Course" https://lnkd.in/dhyV59n2

Algunas características que todo DevOps debe tener

Rossana Suarez #RoxsRoss — Tue, 23 Nov 2021 17:15:47 +0000

Empecemos explicando en qué consiste “DevOps”.

Esta cultura busca acercar a los equipos de desarrollo y operaciones, optimizando los procesos durante todo el ciclo de vida del desarrollo de software, desde la codificación hasta el mantenimiento.

Por ello, muchas empresas buscan un perfil DevOps:
un profesional con unas habilidades y conocimientos en una amplia variedad de temas, desde el desarrollo de software hasta las operaciones de infraestructura. Actualmente, no existe una formación oficial para convertirse en ingeniero DevOps por ello a continuación detallamos algunas habilidades y conocimientos que consideramos que debería tener este perfil:

Experiencia con lenguajes de scripting

Para adentrarnos en el mundo DevOps es muy importante tener una base sólida de programación aún sin ser desarrolladores expertos. Los lenguajes más relevantes a día de hoy para tareas relacionadas con DevOps son Bash y Python, aunque recomendamos tener conocimientos de algún lenguaje adicional como por ejemplo: Go, C, C++, PHP, Ruby, Node.js o PowerShell.

Aunque no vayamos a programar sí necesitaremos conocer las tecnologías con las que trabajan los desarrolladores para poder realizar la implementación de las pipelines de integración, así como desarrollar nuestras propias herramientas para la automatización de algunos procesos.

Contenedores y orquestación de contenedores

Muchas empresas abandonan los modelos tradicionales de despliegue de aplicaciones para realizar una transición a un entorno basado en microservicios (generalmente sistemas en contenedores).

Las ventajas del uso de contenedores son múltiples, desde asegurar que lo mismo que se prueba en desarrollo funcionará exactamente igual en todos los entornos, hasta automatizar más fácilmente el despliegue del código en producción.

Por ello, es importante conocer las herramientas para la administración y gestión de contenedores, algunas de estas herramientas incluyen: Docker, Kubernetes, Docker Swarm, ECS y muchas más.

Security Skills

Este es uno de los puntos que añaden más valor como profesional DevOps. Los ingenieros deben tener las habilidades para escribir código seguro para proteger las aplicaciones de ataques no deseados. Unos tiempos de desarrollo más rápidos conllevan un mayor riesgo de que se introduzcan más vulnerabilidades en el código.

Servicios web

Los servidores web se utilizan para satisfacer las solicitudes de contenidos de un sitio web por parte de los usuarios. Si estás interesado en el mundo DevOps seguramente hayas escuchado que existen diferentes tipos de servidores web, por ello os mencionamos los más conocidos: Nginx, Apache, IIS y Tomcat.

Implementación de infraestructura como código

Independientemente del entorno o del sistema operativo, un buen DevOps debe tener conocimientos sólidos en la administración de infraestructura y sistemas operativos, y ser capaz de automatizar el despliegue y configuración de la misma usando herramientas de infraestructura como código. Las herramientas más relevantes en este sector son Terraform y CloudFormation, aunque esta última solo sirve para AWS.

Automatización de configuración como código

Ya sea para aprovisionar aplicaciones y sus configuraciones, crear usuarios, recursos, automatizar las tareas propias de la administración de sistemas; las herramientas de automatización de configuración permiten mantener un estado consistente a lo largo del tiempo y de la infraestructura gestionada. Algunas de las herramientas más populares para esta automatización son Ansible, Chef, Puppet y Salt.

Implementación de despliegues CI/CD

Para este puesto necesitarás un profundo conocimiento de la esencia de DevOps: la implementación de despliegues, conocido como CI/CD. Todo el código se fusiona y, finalmente, se ejecuta la construcción y las pruebas se automatizan. El despliegue de producción requerirá sobre todo la creación de nuevos contenedores, automatizando los procesos mediante scripts. Algunas herramientas que debe conocer son: Gitlab CI, GitHub Actions, Bamboo, Azure DevOps, Jenkins, Travis CI, TeamCity y Circle CI

Cloud Computing

La nube y los DevOps generalmente van juntos de la mano. De un ingeniero DevOps se espera que sepa manejar las distintas plataformas cloud y las herramientas de las mismas para adaptarse mejor a las necesidades, y buscar soluciones para cada cliente o proyecto. Además, también deberá conocer las diferentes plataformas en la nube para sopesar los pros y los contras de utilizar servicios IaaS frente a PaaS, y otros servicios gestionados para diseñar y recomendar soluciones. Plataformas como AWS, Azure, Google Cloud Platform, etc deben ser herramientas conocidas por un ingeniero DevOps.

Monitorización de la infraestructura

Una de las partes fundamentales del trabajo de un DevOps es la de saber qué ocurre en todo momento en la aplicación una vez finaliza su etapa de desarrollo.

Por ello, monitorizar la infraestructura es una tarea esencial, ya que permite visualizar los eventos y recibir alertas en tiempo real. Algunas de las herramientas DevOps para la monitorización, que ayudan a los equipos de desarrollo y operaciones a trabajar juntos de forma eficaz, son: Prometheus, Grafana, Sensu, y New Relic Infrastructure.

Metodologías ágiles

Un DevOps debe dominar las metodologías ágiles que le permitan realizar un desarrollo iterativo e incremental. Esta metodología tiene como eje central el desarrollo iterativo con enfoque incremental y evolutivo. Esto quiere decir que el desarrollo del software es dividido o fragmentado en sprints o tareas más pequeñas. Por ello, existen metodologías como Kanban o Scrum, y herramientas que las ofrecen o soportan, como Jira.

Soft skills

No basta con ser bueno en codificación y automatización. Un perfil DevOps implica también que debe tener soft skills como la comunicación, flexibilidad, aprendizaje, entre otras. Como ingeniero de DevOps, tienes que colaborar con los desarrolladores, el equipo de QA, los equipos de operaciones y las partes interesadas de alto nivel de la empresa. También puedes tener que involucrar a terceros y, por supuesto, tener en cuenta al cliente final. Por esa razón, las soft skills son igual de importantes que las habilidades técnicas.

Colaboración y Comunicación

Dado la posición donde se encuentra, un ingeniero DevOps debe tener la capacidad de trabajar en equipo, por ello la colaboración y la comunicación son cruciales. Un ingeniero DevOps debe proporcionar una funcionalidad cruzada, es decir, romper las barreras entre las operaciones de TI y el desarrollo. Esto significa que los ingenieros DevOps tienen que trabajar estrechamente con los ingenieros de software. Esto requiere excelentes habilidades de comunicación y colaboración para cualquier persona que desee desempeñar esta función clave de un ingeniero de DevOps.

Flexibilidad

Para un ingeniero DevOps una de las características más destacables es ser flexible. Tener la habilidad de desarrollar continuamente e integrar nuevos sistemas y operaciones adaptándose en todo momento a los cambios en el código. Además los ingenieros deben sentirse cómodos trabajando en diferentes áreas según el momento lo requiera en el proceso de desarrollo de la aplicación.

En conclusión, un perfil DevOps puede ser un desarrollador que se haya adentrado en el mundo de la administración de sistemas, obteniendo experiencia en la gestión de sistemas operativos, networking, aprovisionamiento de software y configuración, etc; o bien puede ser que parta de ser un sysadmin que se haya adentrado en el mundo del desarrollo conociendo al menos un par de lenguajes de programación y los requerimientos para hacer funcionar el software. Cómo ves, el perfil de ingeniero DevOps es muy polivalente.

“Considero que un buen DevOps es aquel que tiene conocimientos de ambos mundos independientemente de cual sea su origen”

Linkedin Link

Claves para una aplicación web en la nube

Rossana Suarez #RoxsRoss — Mon, 15 Nov 2021 17:45:33 +0000

Claves para una aplicación web en la nube

no trabajar con datos en local

La elasticidad implica la creación y destrucción de máquinas/instancias de manera dinámica. Por tanto, hay que tener presente que los datos de un servidor serán destruidos cuando se pare. Nuestra aplicación web en la nube tiene que estar preparada para tal eventualidad. Por ejemplo, si nuestra aplicación permite a los usuarios subir ficheros para que luego éstos sean consultados por el resto de usuarios, no podremos ubicarlos en un directorio local del servidor que atienda la petición.

Los diferentes proveedores nos ofrecen soluciones donde alojar nuestros ficheros para poder ser accedidos por las diferentes instancias de nuestra aplicación e incluso, en caso necesario, otros servicios.

Un ejemplo sería Elastic File System de AWS o File Storage de Azure.

No usar datos en sesión de usuario en el servidor

Los datos de sesión son información útil de cada usuario que se pueden guardar en el servidor. Habitualmente, son necesarios para un correcto funcionamiento de la aplicación. Estamos en la misma situación que el punto anterior. Para que nuestra aplicación web en la nube pueda beneficiarse de la elasticidad necesitamos dejar de depender del entorno en el cual se está ejecutando nuestra aplicación. Por tanto, requerimos de algún servicio que permita almacenar esta información y pueda ser accesible de manera rápida.

Para gestionar estas situaciones, los entornos Cloud nos ofrecen soluciones de base de datos de memoria como ElastiCache en AWS o Azure Redis Cache en Azure.

Utilizar cache para el contenido estático

El uso de cache hace que nuestra aplicación se libere de gestionar aquellas peticiones en las que el contenido no se modifica (p.e. una imagen). Si a esto le sumamos que dicha respuesta se ofrece desde diferentes partes del mundo en función de la situación geográfica del origen, se mejora la velocidad y se reduce el consumo de recursos en nuestros servidores. No obstante, la aplicación web en la nube tiene que ser consciente de este hecho para poder gestionar estas peticiones y controlar cuando tiene, o no, que actualizar un contenido.

Servicios como Cloud Front de AWS o Content Delivery Network de Azure están diseñados con este propósito.

Desplegar nuevas funcionalidades sin pérdida de servicio

El último punto que, en nuestra opinión, una aplicación web en la nube debe cumplir, es realizar despliegues sin pérdida de servicio. Después, realizar pruebas con un entorno idéntico al productivo y garantizar, en caso de problemas, la vuelta a la versión anterior. Esto debería hacerse de manera rápida y transparente para los usuarios.

Diseñar y construir este tipo de procesos puede resultar complicado, ya que requiere de amplios conocimientos de infraestructura, así de como de la tecnología utilizada por cada proveedor. Solo los podremos implementar con éxito si establecemos sistemas automatizados de control de cambios, despliegue, y gestión de la infraestructura.