Category: Automatizacion

Categories
Automatizacion dev web

Desarrollo de aplicaciones sin servidor

El desarrollo de aplicaciones sin servidor, también conocido como serverless, es un enfoque moderno en la industria del desarrollo de software que ha ganado popularidad en los últimos años. Aunque el nombre puede ser engañoso, no significa que las aplicaciones no necesiten servidores, sino que los desarrolladores pueden centrarse exclusivamente en escribir el código de la aplicación, sin tener que preocuparse por la infraestructura subyacente necesaria para su ejecución.

En el desarrollo sin servidor, en lugar de gestionar servidores y configuraciones, los desarrolladores pueden aprovechar servicios en la nube que ofrecen plataformas de ejecución de código como AWS Lambda, Azure Functions o Google Cloud Functions. Estos servicios se encargan de ejecutar el código de manera escalable y automatizada, gestionando la infraestructura de manera transparente para los desarrolladores.

Una de las principales ventajas del desarrollo sin servidor es la eliminación de la necesidad de administrar y escalar servidores, lo que reduce la carga de trabajo operativa y permite a los equipos de desarrollo enfocarse en la lógica de negocio y la funcionalidad de la aplicación. Además, el modelo de precios basado en el consumo de recursos utilizados resulta rentable, ya que los desarrolladores solo pagan por la cantidad de tiempo que su código se está ejecutando.

El desarrollo sin servidor permite la creación de aplicaciones altamente escalables y tolerantes a fallos, ya que los servicios en la nube gestionan automáticamente el escalado de acuerdo con la carga de trabajo y se encargan de la redundancia y la disponibilidad. Esto facilita el desarrollo de aplicaciones ágiles y flexibles que pueden adaptarse rápidamente a las necesidades cambiantes del negocio.

En resumen, el desarrollo de aplicaciones sin servidor es un enfoque que permite a los desarrolladores centrarse en escribir el código de la aplicación, mientras que la infraestructura subyacente es administrada por servicios en la nube. Esto proporciona ventajas como mayor productividad, escalabilidad automática y costos optimizados, lo que lo convierte en una opción atractiva para el desarrollo de software moderno.

Categories
Automatizacion Linux sysadmin

Crear y configurar llaves SSH en Ubuntu 20.04 Linux

En esta ocasión demostraremos cómo crear llaves rsa y ecdsa para poder autenticarse a un equipo remoto

Procedimiento

Instalar dependencias (ssh-keygen, ssh-copy-id)

Para crear las llaves se utilizará ssh-keygen y para instalar la llave creada en el equipo remoto se utilizará ssh-copy-id. Ambos paquetes pueden instalarse con el siguiente comando

sudo apt-get update && sudo apt-get install -y ssh-keygen ssh-copy-id

Generar llaves

Para generar la llave es necesario especificar por lo menos 2 argumentos

  • Algoritmo a utilizar
  • Longitud de la llave, este argumento depende de la opción de algoritmo seleccionada ya que para algunos de ellos se cuenta con una longitud máxima

El algoritmo se especifica con la opción -t y la longitud con la opción -b. Una llave utilizando el algoritmo RSA y una longitud de 4096 bits luce de la siguiente forma

ssh-keygen -t rsa -b 4096

El comando anterior solicitará el nombre del archivo en donde se almacenarán las llaves, si se desea especificar el nombre basta con agregar el argumento -f. El siguiente comando creará una llave usando el algoritmo ecdsa y una llave de 521 bits en el archivo y ruta /home/usuario/millave

ssh-keygen -t ecdsa -b 521 -f /home/usuario/millave

Si la creación de las llaves es exitosa deben de haberse creado 2 archivos en la ruta especificada. Uno con el nombre de la llave sin ninguna terminación de archivo (.doc, .java. crt, etc) y otro con terminación .pub el cual es la llave pública. El archivo sin terminación debe mantenerse en un lugar bien protegido

Copiar llaves a equipo remoto

Para poder utilizar las llaves ssh generadas es necesario que el equipo remoto cuente con la llave pública. Copiaremos la llave recién creada millave con el comando ssh-copy-id

ssh-copy-id -i /home/usuario/millave usuario@equipo-remoto

El comando anterior agrega la llave publica al archivo authorized_keys en el equipo remoto.

Es posible validar que la llave fue instalada de forma correcta conectándonos al equipo especificando la llave privada (la que no tiene terminación)

ssh -i /home/usuario/millave usuario@equipo-remoto

Categories
Automatizacion Linux Raspberry

Cómo crear un espejo local de los repositorios de Ubuntu

Si has tenido que instalar o actualizar paquetes en más de un par de servidores, podrás haberte dado cuenta que la descarga de paquetes está limitada en mayor medida al ancho de banda contratado con nuestro proveedor de internet y en menor a la tarjeta de red del propio equipo. En este tipo de situaciones resulta conveniente tener un repositorio local para acelerar este proceso. A continuación mostraré cómo configurar un espejo local corriendo en Ubuntu 18.04 y utilizando una carpeta NFS donde estarán alojados todos los paquetes.

Requisitos

  • Permisos de administrador/root en el servidor que servirá de repositorio
  • Carpeta compartida NFS o espacio local de por lo menos 200 GB
  • Conexión a internet para descargar los paquetes del espejo de Ubuntu

Instrucciones

Instalación de Apache2

Instalaremos Apache como servidor web, para que los demás servidores puedan obtener los archivos del espejo.

# apt-get update && apt-get install apache2

Ahora habilitaremos el servicio de apache

# systemctl enable apache2

Ahora Apache debe de estar funcionando, validaremos esto con el comando curl

$ curl localhost

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml">  <!--    Modified from the Debian original for Ubuntu    Last updated: 2016-11-16    See: https://launchpad.net/bugs/1288690  -->  <head>

Si obtenemos texto similar al anterior quiere decir que Apache está funcionando de forma correcta.

Montar NFS en el sistema de archivos

Ahora montaremos la carpeta compartida NFS en nuestro servidor con el comando mount

# mount -t nfs 192.168.0.120:/volume1/mirror /var/www/html/ubuntu/

Para que la carpeta se monte de forma automática si el servidor es reiniciado haremos el montaje persistente editando el archivo /etc/fstab

# nano /etc/fstab

192.168.0.120:/volume1/mirror   /var/www/html/ubuntu nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Una vez que el punto de montaje está listo, crearemos las carpetas donde configuraremos apache

# mkdir -p /var/www/html/ubuntu
# chown www-data:www-data /var/www/html/ubuntu

Instalación de apt-mirror

apt-mirror nos permitirá descargar los paquetes del espejo de Ubuntu

# apt-get install apt-mirror

Después configuraremos la lista de repositorios que estaremos alojando localmente, para obtener mejores resultados seleccionaremos la lista de repositorios que se encuentran en el archivo /etc/apt/sources.list

# cat /etc/apt/sources.list

## Note, this file is written by cloud-init on first boot of an instance
## modifications made here will not survive a re-bundle.
## if you wish to make changes you can:
## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/cloud.cfg
##     or do the same in user-data
## b.) add sources in /etc/apt/sources.list.d
## c.) make changes to template file /etc/cloud/templates/sources.list.tmpl

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://ports.ubuntu.com/ubuntu-ports bionic main restricted
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://ports.ubuntu.com/ubuntu-ports bionic-updates main restricted
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-updates main restricted
....

En esta ocasión solo seleccionaremos las entradas deb sin comentarios #, ya que las entradas deb-src incrementan los requisitos de almacenamiento en hasta 800 GB.

Ahora que contamos con la lista de repositorios a alojar, editaremos el archivo /etc/apt/mirror.list

Antes de editarlo realizaremos una copio de respaldo con el siguiente comando

# cp /etc/apt/mirror.list /etc/apt/mirror.list.bk

Ahora editaremos el archivo de configuración /etc/apt/mirror.list

# nano /etc/apt/mirror.list

############# config ##################
#
set base_path    /var/www/html/ubuntu
#
# set mirror_path  $base_path/mirror
# set skel_path    $base_path/skel
# set var_path     $base_path/var
# set cleanscript $var_path/clean.sh
# set defaultarch  <running host architecture>
# set postmirror_script $var_path/postmirror.sh
# set run_postmirror 0
set nthreads     20
set _tilde 0
#
############# end config ##############
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic main restricted

deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic-updates main restricted

deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic universe
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic-updates universe


deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic multiverse
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic-updates multiverse

deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic-backports main restricted universe multiverse


deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic-security main restricted
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic-security universe
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports bionic-security multiverse

En este caso modificamos los campos

  • set base_path – Lugar donde se alojarán los paquetes del espejo
  • arch=arm64 – Para indicar que solo queremos descargar los paquetes de arquitectura arm64. Si piensas alojar los paquetes para todas las arquitecturas puedes eliminar esta opción del código para que quede de la siguiente forma
deb http://ports.ubuntu.com/ubuntu-ports bionic-security multiverse

Una vez modificado el archivo de configuración, copiaremos el script postmirror.sh, que se ejecutará una vez que se hayan descargado todos los paquetes

# mkdir -p /var/www/html/ubuntu/var
# cp cp /var/spool/apt-mirror/var/postmirror.sh /var/www/html/ubuntu/var/

Ahora es tiempo de descargar los paquetes, ten en cuenta que esto puede tardar un par de horas dependiendo de nuestra conexión a internet, por lo que recomendamos hacerlo durante la noche. De no ser posible descargar los paquetes en un solo intento, podemos reiniciar la descarga en cualquier momento.

# apt-mirror
Downloading 346 index files using 20 threads...
Begin time: Sun May 16 16:44:01 2021
[20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]... [11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]... [0]... 
End time: Sun May 16 16:44:05 2021

Processing translation indexes: [TTTTTTTTTTTTTTTTTTTTTTT]

Downloading 1137 translation files using 20 threads...
Begin time: Sun May 16 16:44:05 2021
[20]... [
....

End time: Sun May 16 16:44:09 2021

Processing DEP-11 indexes: [DDDDDDDDDDDDDDDDDDDDDDD]

Downloading 146 dep11 files using 20 threads...
Begin time: Sun May 16 16:44:10 2021
[20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]... [11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]... [0]... 
End time: Sun May 16 16:44:11 2021

Processing indexes: [PPP

Finalizado el script, habremos descargado todos los paquetes del espejo, crearemos un cronjob para ejecutar apt-mirror todos los días a las 2 am, y así obtener los nuevos paquetes del espejo.

# crontab -e
00 	02 	*	 *	 *	/usr/bin/apt-mirror

Configurar los servidores para utilizar el repositorio local

En cada servidor donde deseamos utilizar el espejo local modificaremos el archivo /etc/apt/sources.list para reemplazar ports.ubuntu.com por la dirección IP/dominio de nuestro servidor funcionando como espejo.

## Note, this file is written by cloud-init on first boot of an instance
## modifications made here will not survive a re-bundle.
## if you wish to make changes you can:
## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/cloud.cfg
##     or do the same in user-data
## b.) add sources in /etc/apt/sources.list.d
## c.) make changes to template file /etc/cloud/templates/sources.list.tmpl

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic main restricted
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates main restricted
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic universe
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic universe
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates universe
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic multiverse
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic multiverse
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates multiverse
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-backports main restricted universe multiverse
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-backports main restricted universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu bionic partner
# deb-src http://archive.canonical.com/ubuntu bionic partner

deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports/ bionic-security main restricted
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-security main restricted
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports/ bionic-security universe
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-security universe
deb https://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports/ bionic-security multiverse
# deb-src http://ports.ubuntu.com/ubuntu-ports bionic-security multiverse

El espejo que acabamos de configurar agrega ubuntu-mirror/ports.ubuntu.com/ a la ruta de paquetes, por lo que hay que tomar en cuenta esta ruta al archivo de configuración.
En el ejemplo anterior utilizamos un nombre de dominio, puedes reemplazar archive.nestortechtips.online por la dirección IP del servidor.

En el servidor cliente, validaremos los cambios ejecutando el siguiente comando

# apt-get update
Hit:1 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic InRelease
Get:2 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates InRelease [88.7 kB]
Get:3 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-backports InRelease [74.6 kB]
Get:4 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-security InRelease [88.7 kB]
Ign:5 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates/main arm64 Packages
Ign:6 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates/universe arm64 Packages
Get:7 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates/main arm64 Packages [1264 kB]
Get:8 http://archive.nestortechtips.online/ubuntu/mirror/ports.ubuntu.com/ubuntu-ports bionic-updates/universe arm64 Packages [1527 kB]
Fetched 3053 kB in 2s (1394 kB/s)                                              
Reading package lists... Done

El resultado del comando anterior confirma que los paquetes están siendo actualizados desde el espejo local.

Conclusión

Descargar actualizaciones puede tomar largo tiempo desde un espejo de internet, con un espejo local podemos aprovechar que la mayoría del equipo de red moderno pone a nuestra disposición velocidades Gigabit (1000 Mbits/s), que pueden no estar disponibles por nuestro proveedor de internet, o si lo están puede que no mantengan está velocidad de forma constante/estable. Con el repositorio local podemos mitigar este cuello de botella o al menos reducir su impacto.

Categories
Automatizacion Contenedores Kubernetes

Provisionador dinámico de volumenes de Kubernetes con servidor NFS

El motivo por el que escribo esta publicación es el final de soporte del chart de Helm que utilizaba para crear el provisionador dinámico de volúmenes en Kubernetes. Después de una búsqueda rápida por Internet descubrí que los tutoriales/repositorios existentes no son muy claros al momento de explicar como migrar de Helm o, como lo haré en este caso, cómo crear los objetos necesarios para configurar el provisionador.

Requisitos

  • Acceso al clúster de Kubernetes con kubectl
  • Acceso al servidor NFS desde cada nodo del clúster de Kubernetes (este requisito se puede satisfacer instalando el paquete nfs-common)

Procedimiento

Para poder configurar el provisionador necesitamos contar con los siguientes datos del servidor NFS

  • Dirección IP o hostname
  • Ruta del directorio compartido por NFS

Creación de roles

En las versiones modernas de Kubernetes es necesario crear los Roles, ClusterRoleBindings y ServiceAccounts que nos permitan crear el StorageClass dentro del clúster. En tu editor de texto favorito crea el archivo rbac.yaml y agrega el siguiente contenido, no olvides reemplazar nfs-nas por el valor del Namespace donde deseas crear el provisionador: 


apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # Reemplaza con el nombre del Namespace donde se creará el provisionador
  namespace: nfs-nas
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # Reemplaza con el nombre del Namespace donde se creará el provisionador
    namespace: nfs-nas
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # Reemplaza con el nombre del Namespace donde se creará el provisionador
  namespace: nfs-nas
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # Reemplaza con el nombre del Namespace donde se creará el provisionador
  namespace: nfs-nas
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # Reemplaza con el nombre del Namespace donde se creará el provisionador
    namespace: nfs-nas
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

Una vez que el archivo rbac.yaml se encuentre configurado de forma correcta podemos crear los roles con el siguiente comando: 


kubectl apply -f rbac.yaml

Creación de Deployment

En tu editor de texto favorito crea el archivo nfs-provisioner-deployment.yaml y agrega el siguiente contenido: 


apiVersion: apps/v1
kind: Deployment
metadata:
  name: nas-provisioner
  namespace: nfs-nas
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client-provisioner
      release: nas-provisioner
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
        release: nas-provisioner
    spec:
      containers:
      - env:
        - name: PROVISIONER_NAME
          value: nfs-nas
        - name: NFS_SERVER
          value: 192.168.4.19
        - name: NFS_PATH
          value: /volume1/storageclass/
        image: quay.io/external_storage/nfs-client-provisioner
        imagePullPolicy: IfNotPresent
        name: nfs-client-provisioner
        volumeMounts:
        - mountPath: /persistentvolumes
          name: nfs-client-root
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      serviceAccount: nfs-client-provisioner
      serviceAccountName: nfs-client-provisioner
      volumes:
      - name: nfs-client-root
        nfs:
          path: /volume1/storageclass/
          server: 192.168.4.19

En el archivo anterior debemos modificar un par de valores de acuerdo a los datos de nuestro servidor NFS. En las variables de ambiente debemos de cambiar el valor de:

  • PROVISIONER_NAME – Nombre que queremos asignar al provisionador, este valor será el que se utilice en el siguiente paso
  • NFS_SERVER – Dirección IP o hostname del servidor NFS
  • NFS_PATH – Ruta de la carpeta compartida en el servidor NFS
  • image – En caso de utilizar una Raspberry cambiar la imagen por quay.io/external_storage/nfs-client-provisioner-arm
  • namespace – Nombre del namespace configurado en el paso anterior

Una vez configurados los valores en el archvio creamos el Deployment con el siguiente comando: 


kubectl apply -f nfs-provisioner-deployment.yaml

Creación de StorageClass

Finalmente crearemos el StorageClass en Kubernetes. Para hacerlo debemos crear el archivo provisioner-class.yaml con el siguiente contenido: 


allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  labels:
    app: nfs-client-provisioner
    release: nas-provisioner
  name: nfs-nas
parameters:
  archiveOnDelete: "true"
provisioner: nfs-nas
reclaimPolicy: Delete
volumeBindingMode: Immediate

En el archivo anterior no olvidemos cambiar los valores siguientes:

  • name – Nombre del Provisionador que definimos en el paso anterior
  • provisioner – Nombre que tendrá el Provisionador en nuestro clúster de Kubernetes. Se recomienda que sea el mismo valor que asignamos en name

Para crear la clase es suficiente con ejecutar el siguiente comando: 


kubectl apply -f provisioner-class.yaml

Una vez realizados los pasos anteriores podremos crear PVC para que nuestras Workloads pueden disponer de un almacenamiento no volátil

Contribuciones

Puedes contribuir utilizando Pull Requests en el repositorio correspondiente. De no existir crea un archivo contrib.txt, de existir modifica el archivo para agregar tu nombre de usuario o correo. Por ejemplo:

  • fulano.detal@correo.com
  • perengano

Créditos

El contenido de esta publicación corresponde al repositorio homónimo en Github.

Categories
Ansible Automatizacion Raspberry

Cómo instalar Ansible en Ubuntu 18.04

En esta ocasión mostraré cómo instalar Ansible en nuestro equipo y así poder automatizar la gestión de los demás servidores en nuestro ambiente de trabajo.

Agregar repositorio de Ansible a servidor central

Lo primero que hay que realizar es agregar el repositorio de paquetes al servidor central/maestro desde el cuál se encargará de ejecutar los playbooks en nuestro ambiente. Para hacerlo solo hay que ejecutar el siguiente comando:

usuario@central:~$ sudo apt-add-repository ppa:ansible/ansible

Después hay que actualizar la lista de paquetes disponibles para poder realizar la instalación de Ansible

usuario@central:~$ sudo apt-get update

A continuación instalaremos el paquete ansible

usuario@central:~$ sudo apt-get install ansible -y

Finalizada la instalación podemos comprobar la versión instalada con el siguiente comando:

usuario@central:~$ ansible --version
ansible 2.9.14
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/usuario/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.17 (default, Jul 20 2020, 15:37:01) [GCC 7.5.0]

El comando nos mostrará la versión instalada, en mi caso se instaló la versión 2.9.14.

Ahora que ansible se encuentra instalado puedes agregar la lista de servidores a tu inventario o ejecutar tus playbook.

Puedes consultar más información sobre ansible o ejemplos en la documentación oficial: