En este post vamos a ver como desplegar wordpress con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de MariaDB para la base de datos que vamos a utilizar y el otro el propio de WordPress con la aplicación, este servicio irá desplegado, sobre la misma máquina dónde ya desplegamos un docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para wordpress apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de MariaDB y WordPress:
• sudo mkdir -p /opt/docker/wprgs/wprgsdb/data
• sudo mkdir -p /opt/docker/wprgs/wprgsdb/config
• sudo mkdir -p /opt/docker/wprgs/wprgsapp/config
• sudo chmod -R 755 /opt/docker/wprgs/wprgsdb
• sudo chmod -R 755 /opt/docker/wprgs/wprgsapp

• Ahora creamos una red personalizada para nuestro proyecto, sudo docker network create —subnet 172.25.3.0/24 –gateway 172.25.3.1 -d bridge wprgs-net, con sudo docker network ls vemos la redes que tenemos configuradas y con sudo docker network inspect wprgs-net, vemos la configuración de la red que hemos creado:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de MariaDB, para ello, nos situamos en cd /opt/docker/wprgs/wprgsdb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• MYSQL_ROOT_PASSWORD=clave_muy_segura_root_db
• MYSQL_DATABASE=wprgsdb
• MYSQL_USER=wprgsuser
• MYSQL_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

wprgs-db:

image: mariadb:12.2

container_name: wprgs-db

restart: unless-stopped

env_file: .env

environment:

– MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

volumes:

– /opt/docker/wprgs/wprgsdb/data:/var/lib/mysql

– /opt/docker/wprgs/wprgsdb/config:/etc/mysql/conf.d:ro

networks:

– wprgs-net

networks:

wprgs-net:

name: wprgs-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de wordpress app, para ello, nos situamos en cd /opt/docker/wprgs/wprgsapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:

WORDPRESS_DB_USER=wprgsuser

WORDPRESS_DB_PASS=clave_muy_segura_db

WORDPRESS_DB_NAME=wprgsdb

• Nos creamos el fichero docker-compose.yaml para el contenedor de wordpress-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

wprgs-app:

image: wordpress:6.9.4-php8.5-apache

container_name: wprgs-app

restart: unless-stopped

ports:

– «8081:80»

env_file: .env

environment:

– WORDPRESS_DB_HOST=wprgs-db:3306

– WORDPRESS_DB_USER=${WORDPRESS_DB_USER}

– WORDPRESS_DB_PASSWORD=${WORDPRESS_DB_PASS}

– WORDPRESS_DB_NAME=${WORDPRESS_DB_NAME}

– WORDPRESS_CONFIG_EXTRA=define(‘WP_HOME’,’https://wprgs.ragasys.net’); define(‘WP_SITEURL’,’https://wprgs.ragasys.net’); if (isset($$_SERVER[‘HTTP_X_FORWARDED_PROTO’]) && $$_SERVER[‘HTTP_X_FORWARDED_PROTO’] === ‘https’) { $$_SERVER[‘HTTPS’] = ‘on’; }

volumes:

– /opt/docker/wprgs/wprgsapp/config:/var/www/html

networks:

– wprgs-net  # Para comunicar con la DB

– npm-net    # Para comunicar con Nginx Proxy Manager

networks:

wprgs-net:

external: true

npm-net:

external: true

• Aquí debemos tener en cuenta, que la línea de los puertos 8081:80, la hemos dejado solo para verificar que el servicio se levanta en esos puertos por HTTP, una vez que configuremos nuestro Nginx Proxy Manager para el acceso por HTTPS con los certificados de Let’s Encrypt esta línea la podemos quitar o comentar, y con respecto a la variable WORDPRESS_CONFIG_EXTRA, es para indicarle al wordpress que está detrás de un proxy, también podemos ver que se conecta con la red de Nginx Proxy Manager npm-net, ya qu el acceso será a través de nuesro proxy inverso.
• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/wprgs/wprgsdb/.env
• sudo chmod 600 /opt/docker/wprgs/wprgapp/.env

• Ahora, iniciamos primero el contenedor de MariaDB, cd /opt/docker/wprgs/wprgsdb/, sudo docker compose up -d:

• Iniciamos el contenedor de wprgs-app, cd /opt/docker/wprgs/wprgsapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para wordpress.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: wprgs-app
• Puerto: 80
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos ya tenemos acceso a nuestro wordpress a través de nuestro proxy inverso con Nginx Proxy Manager, ahora nos va a pedir lo típico tras el primer acceso:

• Introducimos las credenciales y ya estamos dentro de nuestro wordpress, listo para empezar a publicar:

Saludos y espero que os resulte de ayuda

La entrada Desplegar WordPress con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar keycloak con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de PostgreSQL para la base de datos que vamos a utilizar y el otro el propio de keycloak con la aplicación, este servicio irá desplegado, sobre la misma máquina dónde ya desplegamos un docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

Keycloak es una solución de código abierto para la gestión de identidades y accesos (IAM), diseñada para asegurar aplicaciones y servicios modernos, permite añadir funciones de inicio de sesión único (SSO), autenticación, autorización y federación de usuarios (LDAP/AD, redes sociales) mediante estándares como OpenID Connect, OAuth 2.0 y SAML 2.0.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para keycloak apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de postgreSQL y keycloak:
• sudo mkdir -p /opt/docker/keycloakdb/data
• sudo mkdir -p /opt/docker/keycloakapp/config
• sudo chmod -R 755 /opt/docker/keycloakdb
• sudo chmod -R 755 /opt/docker/keycloakapp

• Al directorio config de /opt/docker/keycloakapp le cambiamos el propietario con sudo chown -R 1000:1000 /opt/docker/keycloakapp/config, con esto le estamos diciendo al sistema, que esta carpeta ahora le pertenece al usuario 1000 (Keycloak), como el contenedor es el dueño, ya tiene permiso total por defecto para crear los archivos de transacciones para los logs:

• Ahora creamos una red para nuestro proyecto, sudo docker network create keycloak-net:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de postgreSQL, para ello, nos situamos en /opt/docker/ keycloakdb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• POSTGRES_DB=keycloak
• POSTGRES_USER=keycloakuser
• POSTGRES_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de postgreSQL en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

keycloak-db:

image: postgres:16.6

container_name: keycloak-db

restart: unless-stopped

env_file: .env

volumes:

– /opt/docker/keycloakdb/data:/var/lib/postgresql/data

networks:

– keycloak-net

networks:

keycloak-net:

name: keycloak-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de keycloak-app, para ello, nos situamos en /opt/docker/keycloakapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• KC_DB=postgres
• KC_DB_URL=jdbc:postgresql://keycloak-db:5432/keycloak
• KC_DB_USERNAME=keycloakuser
• KC_DB_PASSWORD=clave_muy_segura_db
• KEYCLOAK_ADMIN=admkck
• KEYCLOAK_ADMIN_PASSWORD=clave_admin_keycloak

• Nos creamos el fichero docker-compose.yaml para el contenedor de keycloak-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

keycloak-app:

image: quay.io/keycloak/keycloak:26.1.3

container_name: keycloak-app

command:

– start-dev

– –proxy-headers=xforwarded

– –hostname=keycloak.ragasys.net

– –http-enabled=true

– –hostname-strict=false

restart: unless-stopped

env_file: .env

environment:

– KC_DB=${KC_DB}

– KC_DB_URL=${KC_DB_URL}

– KC_DB_USERNAME=${KC_DB_USERNAME}

– KC_DB_PASSWORD=${KC_DB_PASSWORD}

– KEYCLOAK_ADMIN=${KEYCLOAK_ADMIN}

– KEYCLOAK_ADMIN_PASSWORD=${KEYCLOAK_ADMIN_PASSWORD}

volumes:

– /opt/docker/keycloakapp/config:/opt/keycloak/data

networks:

– keycloak-net  # Para comunicar con la DB

– internal-net  # Para comunicar con Nginx Proxy Manager

networks:

keycloak-net:

external: true

internal-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/keycloakdb/.env
• sudo chmod 600 /opt/docker/keycloakapp/.env

• Ahora, iniciamos primero el contenedor de postgreSQL, cd /opt/docker/keycloakdb/, sudo docker compose up -d:

• Iniciamos el contenedor de keycloak-app, cd /opt/docker/keycloakapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para keycloak.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: keycloak-app
• Puerto: 8080
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Rueda configuración avanzada:
• proxy_set_header Host $host;
• proxy_set_header X-Real-IP $remote_addr;
• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
• proxy_set_header X-Forwarded-Proto https;
• proxy_set_header X-Forwarded-Ssl on;
• # Esto es vital para que Keycloak no intente redirigir a http interno
• proxy_redirect http:// https://;
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos ya tenemos acceso a nuestro keycloak a través de nuestro proxy inverso con Nginx Proxy Manager:

• Nos hemos creado un nuevo realm para nuestras aplicaciones:

• El rol del Realm master, el realm master es puramente para la administración del servidor de Keycloak.
• Se usa para crear otros Realms.
• Se usa para crear usuarios que sean administradores globales.
• Regla de oro, no registres tus aplicaciones (como phpIPAM, Nextcloud, etc.) ni a tus usuarios finales dentro de master.
• Por qué crear un Realm nuevo (Ragasys-Apps), al crear un realm específico para tus aplicaciones:
• Aislamiento, si te equivocas configurando algo en el realm de tus apps, el acceso de administración en master sigue funcionando.
• Seguridad, puedes tener políticas de contraseñas y 2FA distintas para los administradores en el master y para los usuarios en el nuevo realm.
• Orden, mantemos limpios los logs y la base de datos de usuarios.
• Sobre el real que hemos creado, accedemos a Authentication > Required actions > Configure OTP habilitamos Configure OTP y Set as default action, esto obligará a configurar el 2FA a todos los usuarios:

Saludos y espero que os sea de ayuda

La entrada Desplegar keycloak con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar phpIPAM con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de MariaDB para la base de datos que vamos a utilizar y el otro el propio de phpIPAM con la aplicación.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para phpIPAM apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de mariadb y phpipam:
• sudo mkdir -p /opt/docker/mariadb/data
• sudo mkdir -p /opt/docker/mariadb/config
• sudo mkdir -p /opt/docker/phpipam/config
• sudo chmod -R 755 /opt/docker/mariadb /opt/docker/phpipam

• Ahora creamos una red para nuestro proyecto, sudo docker network create phpipam-net:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de MariaDB, para ello, nos situamos en /opt/docker/mariadb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• MYSQL_ROOT_PASSWORD=una_clave_muy_segura_root
• MYSQL_DATABASE=phpipam
• MYSQL_USER=phpipamuser
• MYSQL_PASSWORD=clave_usuario_phpipam

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

phpipam-db:

image: mariadb:latest

container_name: phpipam-db

restart: unless-stopped

env_file: .env

ports:

– «3306:3306»

environment:

– MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

volumes:

– /opt/docker/mariadb/data:/var/lib/mysql

– /opt/docker/mariadb/config:/etc/mysql/conf.d:ro

networks:

– phpipam-net

networks:

phpipam-net:

name: phpipam-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de phpIPAM, para ello, nos situamos en /opt/docker/phpipam, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• IPAM_DATABASE_HOST=192.168.14.17 # IP docker02
• IPAM_DATABASE_USER=phpipamuser
• IPAM_DATABASE_PASS=clave_usuario_phpipam
• IPAM_DATABASE_NAME=phpipam
• IPAM_DATABASE_PORT=3306
• IPAM_BASE_URL=https://phpipam.ragasys.net
• PHPIPAM_TRUSTED_PROXIES=192.168.14.0/24 # Rango de red de docker01
• # IPAM_DISABLE_INSTALLER=1 Luego lo habilitamos

• Nos creamos el fichero docker-compose.yaml para el contenedor de phpIPAM en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

phpipam-web:

image: phpipam/phpipam-www:latest

container_name: phpipam-web

restart: unless-stopped

ports:

– «8080:80»

env_file: .env

environment:

– IPAM_DATABASE_HOST=${IPAM_DATABASE_HOST}

– IPAM_DATABASE_USER=${IPAM_DATABASE_USER}

– IPAM_DATABASE_PASS=${IPAM_DATABASE_PASS}

– IPAM_DATABASE_NAME=${IPAM_DATABASE_NAME}

– IPAM_DATABASE_PORT=${IPAM_DATABASE_PORT}

volumes:

– /opt/docker/phpipam/config:/copy-to-www-html

networks:

– phpipam-net

networks:

phpipam-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/mariadb/.env
• sudo chmod 600 /opt/docker/phpipam/.env

• Ahora, iniciamos primero el contenedor de MariaDB, cd /opt/docker/mariadb/, sudo docker compose up -d:

• Iniciamos el contenedor de phpIPAM, cd /opt/docker/phpipam/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps:

• Accedemos a nuestro contenedor phpIPAM, http://192.168.14.17:8080:

• Voy a migrar de un servidor antiguo que tengo con phpIPAM v1.4, para ello, he realizado un backup de la base de datos que utilizaba este servidor, mysqldump -u phpipam -p phpipam > MIGRATE.sql:

• Copiamos el backup de la base de datos en /opt/docker/mariadb:

• Importamos los datos directamente al contenedor de MariaDB, sudo docker exec -i phpipam-db mariadb -u phpipamuser -p’passworduserdb’ phpipam < /opt/docker/mariadb/MIGRATE.sql:

• Ahora, accedemos a la interfaz web de phpipam y seleccionamos la opción 3, Working installation:

• Introducimos las credenciales de la base de datos que hemos migrado, es decir, la de nuestro servidor phpipam antiguo:

• Y le hacemos un Upgrade a la base de datos:

• Vemos que el Upgrade ha sido correcto, damos clic a Dashboard y vemos que ya tenemos nuestro phpIPAM operativo y migrado de nuestro servidor antiguo:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para phpIPAM.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: IP máquina docker02
• Puerto: 8080
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Como el phpIPAM lo tenemos detrás de un proxy inverso, tenemos que seguir estos pasos para que nos funcione y podamos acceder a la web de administración:
• Sobre Administración > phpIPAM settings configuramos la URL del sitio y guardamos:

• Con sudo docker exec -it phpipam-web sh entramos al contenedor:

• Con apk add –no-cache nano, instalamos el editor nano:

• Accedemos al directorio phpipam y editamos el fichero nano config.docker.php:

• Al final del fichero añadimos estas líneas:

/* — CONFIGURACIÓN FORZADA PARA PROXY Y BASE DE DATOS — */

// 1. Forzar que phpipam sepa que está en la raíz y es HTTPS

define(‘BASE’, «/»);

$_SERVER[‘HTTPS’] = ‘on’;

$_SERVER[‘SERVER_PORT’] = 443;

// 2. Forzar los datos de la Base de Datos (ajusta si tus datos son distintos)

$db[‘host’] = ‘192.168.14.17’;

$db[‘user’] = ‘phpipamuser’;

$db[‘pass’] = ‘phpipampass’; // <— PON AQUÍ TU CONTRASEÑA REAL

$db[‘name’] = ‘phpipam’;

$db[‘port’] = 3306;

/** Disable installation helper **/

define(‘TOOLKIT’, true);

$disable_installer = true;

• Con rm -f config.php y ln -s config.docker.php config.php borramos el enlace simbólico y lo volvemos a crear, con exit salimos del contenedor:

• Como hemos modificado un fichero dentro del contenedor docker de phpIPAM, ese mismo fichero lo guardamos en el volumen que creamos en el docker-compose.yaml, así cuando actualicemos el contenedor, ese fichero también será modificado dentro del contenedor actualizado, sudo docker cp phpipam-web:/phpipam/config.docker.php /opt/docker/phpipam/config/config.docker.php:

• Modificamos de nuevo el fichero docker-compose de phpIPAM con sudo nano docker-compose.yaml y añadimos las líneas:

– /opt/docker/phpipam/config/config.docker.php:/phpipam/config.docker.php:ro

– /opt/docker/phpipam/config/config.docker.php:/phpipam/config.php:ro

• Con sudo docker exec -it phpipam-db mariadb -u root -p accedemos al contenedor de MariaDB:

• Y ejecutamos:
• USE phpipam;
• UPDATE settings SET siteURL = ‘https://phpipam.ragasys.net/’ WHERE id = 1;
• UPDATE settings SET prettyLinks = ‘Yes’ WHERE id = 1;
• exit;

• Sobre la configuración del host de phpipam que configuramos en Nginx Proxy Manager, debemos de agregar esta configuración personalizada:

# Forzar cabeceras de protocolo seguro

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto https;

proxy_set_header X-Forwarded-Ssl on;

# Evitar que el backend envíe redirecciones a http

proxy_redirect http:// https://;

# Desactivar compresión si da problemas con sub_filter

proxy_set_header Accept-Encoding «»;

# Cambiar cualquier mención de http por https en el código de la página

sub_filter ‘http://phpipam.ragasys.net’ ‘https://phpipam.ragasys.net’;

sub_filter_once off;

• Con sudo docker restart phpipam-web reiniciamos el contenedor de phpIPAM:

• Modificamos de nuevo el .env de phpIPAM, cd /opt/docker/phpipam/, nano .env:

• Y descomentamos la línea IPAM_DISABLE_INSTALLER=1:

• Reiniciamos el contenedor de phpIPAM con sudo docker compose up -d:

• Y como vemos ya tenemos acceso a nuestro phpIPAM a través de nuestro proxy inverso con Nginx Proxy Manager:

Saludos y espero que os sea de ayuda

La entrada Desplegar phpIPAM con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar homepage con Docker.

Homepage es un panel de control de aplicaciones moderno, totalmente estático, rápido, seguro, con proxy completo y altamente personalizable, con integraciones para más de 100 servicios y traducciones a varios idiomas, se configura fácilmente mediante archivos YAML o mediante la detección de etiquetas Docker.

• Nos creamos el registro DNS del tipo CNAME para homepage apuntando a la máquina que tiene instalada el Docker:

• Ahora vamos a crear la estructura de directorios y permisos para el contenedor de homepage:
• sudo mkdir -p /opt/docker/homepage/config
• sudo mkdir -p /opt/docker/homepage/icons
• sudo mkdir -p /opt/docker/homepage/images
• sudo chmod -R 775 /opt/docker/homepage

• Así quedaría nuestra estructura de directorios:

• Lo siguiente que haremos será crearnos el archivo docker-compose.yml para homepage, sudo nano /opt/docker/homepage/docker-compose.yml:

• Iniciamos Nginx Proxy Manager, cd /opt/docker/homepage, sudo docker compose up -d:

• Con sudo docker ps -a, vemos el contenedor levantado:

• Con docker exec -it nginxpm sh -c «apk add –no-cache curl >/dev/null 2>&1; curl -sI http://homepage:3000«, comprobamos que Nginx Proxy Manager puede acceder a homepage:

• Ahora nos vamos al panel de administración de Nginx Proxy Manager para crear el Proxy Host:

• Add Proxy Host:

• En la pestaña Details:
• Domain Names: ragasys.eu
• Scheme: http
• Forward Hostname / IP: homepage
• Forward Port: 300
• Websockets Support
• Block Common Exploits
• En la pestaña SSL:
• Seleccionamos en Certificate nuestros certificados SSL
• Marcamos Force SSL
• Marcamos HTTP/2 Support
• Save

• Aquí vemos el host creado y online:

• Si accedemos al host homepage, vemos que ya está utilizando los certificados SSL de Let’s Encrypt, vemos también que nos da un error de validación, es un error bastante común la primera vez que accedemos a Homepage (detrás de un proxy inverso como Nginx Proxy Manager, ahora veremos cómo solucionarlo:

• Para solucionar este error vamos a editar el fichero settings.yml, sudo nano /opt/docker/homepage/docker-compose.yml:

• Y añadimos la variable, HOMEPAGE_ALLOWED_HOSTS: «homepage.ragasys.net,localhost,127.0.0.1»:

• Aplicamos los cambios, cd /opt/docker/homepage, docker compose up -d:

• Accedemos a nuestro host, https://homepage.ragasys.net y vemos que ya tenemos el panel de homepage:

• Ahora vamos a ir configurando los distintos ficheros de homepage, para ir personalizando nuestro panel, esta será la estructura de directorios y los ficheros:

• Empezaremos por el fichero sudo nano settings.yaml:

• sudo nano services.yaml, aquí muestro algunos ejemplos que tenemos que ir completando con todo lo que tenemos en nuestra infraestructura:

• sudo nano widgets.yaml, los widgets para el dashboard:

• sudo nano bookmarks.yaml, los enlaces personales para el dashboard:

• Y así nos iría quedando nuestro panel de Homepage:

Saludos y espero que os sea de ayuda

La entrada Desplegar homepage con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar Nginx Proxy Manager con Docker.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para nginx proxy manager apuntando a la máquina que tiene instalada el Docker:

• Lo primero que vamos a realizar es actualizar nuestro sistema, sudo apt update && sudo apt upgrade -y:

• Instalamos las dependencias necesarias, sudo apt install -y ca-certificates curl gnupg lsb-release:

• Instalamos Docker desde el script oficial, curl -fsSL https://get.docker.com -o get-docker.sh, sudo sh get-docker.sh, rm get-docker.sh:

• Instalamos el plugin de Docker Compose, sudo apt install -y docker-compose-plugin:

• Verificamos las versiones, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para el contenedor de nginx proxy manager:
• sudo mkdir -p /opt/docker/nginxpm/data
• sudo mkdir -p /opt/docker/nginxpm/certs
• sudo chmod -R 755 /opt/docker

• Así quedaría nuestra estructura de directorios:

• Ahora creamos la red interna para Docker, esto permite que los contenedores se comuniquen sin exponer puertos externos, sudo docker network create internal-net:

• Lo siguiente que haremos será crearnos el archivo docker-compose.yml para nginx proxy manager, sudo nano /opt/docker/nginxpm/docker-compose.yml:

• Iniciamos Nginx Proxy Manager, cd /opt/docker/nginxpm, sudo docker compose up -d:

• Aquí vemos el contenedor levantado:

• Ahora accedemos al panel de administración de Nginx Proxy Manager en el puerto 81, el usuario es admin@example.com y la contraseña changeme:

• Editamos el usuario y lo personalizamos a nuestro gusto, Save:

• Cambiamos la contraseña por defecto, Save:

• Esta sería la estructura de directorios que queda configurada para el contenedor Docker de Nginx Proxy Manager:

• Con todo esto, ya tenemos nuestro contenedor Docker de Nginx Proxy Manager operativo, en los siguientes posts veremos, cómo se configuran los certificados SSL, veremos tres formas, dos de ellas con Let´s Encrypt configurado por DNS Challenge, uno con el DNS Provider por Cloudflare y otro con el DNS Provider por Azure así no exponemos hacia fuera los puertos 80 y 443, la tercera forma que veremos con los certificados serán con certificados comprados a una CA y utilizando la parte Custom para añadirlos, y en otros post veremos como desplegar otras aplicaciones con Docker como homepage utilizando el Nginx Proxy Manager con los certificados que hemos añadido, configurando los Host en nuestro Nginx Proxy Manager.
• Aquí os dejo un pequeño apunte con los comando útiles de Docker:

Link descarga en pdf

Saludos y espero que os sea de ayuda

La entrada Desplegar Nginx Proxy Manager con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo agregar nodos Proxmox VE y Proxmox Backup Server a Proxmox Datacenter Manager (PDM).

Proxmox Datacenter Manager es una solución de gestión centralizada de código abierto para infraestructuras distribuidas, con una interfaz web unificada, dónde podemos supervisar y controlar fácilmente múltiples servidores remotos Proxmox, consultar el estado y el rendimiento de un vistazo, y coordinar operaciones clave en clústeres y centros de datos.

Referencia Imagen

La topología utilizada sería la siguiente:

• Para empezar a agregar los nodos de Proxmox VE de nuestro clúster a Proxmox Datacenter Manager, accedemos a Remotos > Agregar > Proxmox VE:

• Sobre Sondear remoto, le indicamos la IP y puerto de nuestro primer nodo Proxmox VE, y la Huella digital, Siguiente:

• La Huella digital la sacamos del certificado de nuestro nodo proxmox VE:

• Sobre Configuraciones, le indicamos el ID del remoto (en este caso, hemos escogido este nombre para el clúster, ya que más adelante vamos a añadir los otros dos nodos del clúster Proxmox VE) y el login para crear el token, Siguiente:

• Sobre Puntos de acceso, le indicamos los otros nodos Proxmox VE de nuestro clúster, Siguiente:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, ya tenemos nuestro clúster Proxmox VE agregado a Proxmox Datacenter Manager:

• Ahora vamos a agregar el servidor Proxmox Backup Server a Proxmox Datacenter Manager, para ello, accedemos a Remotos > Agregar > Proxmox Backup Server:

• Sobre Conexión, le indicamos la IP y puerto de nuestro Proxmox Backup Server, y la Huella digital, Siguiente:

• La Huella digital la sacamos del dashboard de Proxmox Backup Server:

• Sobre Configuraciones, le indicamos el ID del remoto y el login para crear el token, Siguiente:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, ya tenemos nuestro Proxmox Backup Server agregado a Proxmox Datacenter Manager:

Saludos y espero que os sea de ayuda

La entrada Agregar nodos Proxmox VE y Proxmox Backup Server a Proxmox Datacenter Manager se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo instalar Proxmox Datacenter Manager (PDM).

Referencia Imagen

La topología utilizada sería la siguiente:

• Para explicar Proxmox Datacenter Manager en nuestro laboratorio, vamos a desplegarnos una máquina virtual con estas cartacterísticas:

• Nos descargamos la ISO de Proxmox Datacenter Manager, desde su web oficial:

• Aquí tenemos la ISO descargada:

• La montamos en la unidad de CD/DVD de nuestra máquina virtual y procedemos con la instalación, seleccionamos Install Proxmox Datacenter Manager (Graphical):

• Comienza a detectar el hardware para empezar con la instalación:

• Aceptamos el EULA:

• Como podemos ver, aquí tenemos los dos discos duros de 100 GB, clicamos sobre Options:

• Y configuramos el sistema de ficheros como ZFS (RAID1) con los dos discos que tenemos:

• Clic en Next:

• Configuramos el país, zona horaria e idioma del teclado:

• Configuramos la password de root y un email para alertas y notificaciones:

• Configuramos la interface de red, e introducimos los parámetros de TCP/IP:

• Nos muestra un resumen de todas las configuraciones realizadas, y si todo está correcto, damos clic a Install:

• Comienza el proceso de instalación:

• Como podemos ver, la instalación ha finalizado correctamente, nos indica que el acceso web a nuestro Proxmox Datacenter Manager lo podemos hacer por la dirección IP indicada, nosotros accederemos por nombre, ya que tenemos el registro DNS tipo A creado en nuestro servidor de nombres, Reboot:

• Una vez que termina la instalación, reiniciamos nuestra máquina de proxmox datacenter manager y vemos que ya podemos acceder por la consola:

• Como es una máquina virtual sobre un host ESXi, vemos que no tenemos instaladas las VMware Tools, para instalarlas seguimos este post que realizamos hace algunos años:

• Como vemos, ya las tenemos instaladas y en ejecución:

• Realizamos el primer acceso a nuestro Proxmox Datacenter Manager recién instalado:

• Esta sería la interface que tiene a primera vista nuestro Proxmox Datacenter Manager, a medida que empecemos a configurar el servidor iremos viendo las distintas opciones:

• Vamos a configurar nuestro segundo DNS, para ello, accedemos a Configuración > DNS > Edit y añadimos el segundo DNS:

• Para el tema de la red, le vamos a agregar otra tarjeta de red a nuestro Proxmox Datacenter Manager, y vamos a configurar un bond o nic teaming con estas dos interfaces de red con modo de balanceo balance-alb, luego este bond será el que utilicemos en el Linux Bridge, así le daremos redundancia a nivel de red:

• Para realizar las actualizaciones de nuestro PDM, tanto del sistema operativo Debian 13 sobre el que corre Proxmox Datacenter Manager como de la paquetería del propio PDM, tendremos dos tipos de repositorios, los Enterprise en los que tenemos que pagar una suscripción por el soporte, y los del tipo No-Subscription que son free, pero eso sí, no son tan fiables como los Enterprise, en mi caso utilizaremos los del tipo No-Subscription para realizar las actualizaciones, para agregar un repositorio accedemos a Administración > Repositorios:

• Actualizamos nuestro sistema en Administración > Actualizaciones > Refrescar:

• Vemos todas las actualizaciones que tenemos pendientes, Actualizar sistema:

• Una vez actualizado, configuramos la administración de usuarios, roles y permisos, que sería exactamente igual, a como lo hicimos en Proxmox VE, accedemos a Configuración > Control de acceso, y aquí os muestro como quedaría:

• Para la conexión con un dominio Active Directory de Microsoft, hacemos lo mismo que ya vimos en Proxmox VE, aquí os muestro que ya tenemos nuestro domino AD agregado y hemos asignado un tipo de permiso:

• Para terminar las configuraciones iniciales, vamos a unir a nuestro dominio de Active Directory la máquina Proxmox Datacenter Manager, esto también se haría exactamente igual a como lo hicimos con Proxmox VE:

Saludos y espero que os resulte de ayuda

La entrada Instalación y configuraciones iniciales de Proxmox Datacenter Manager (PDM) se publicó primero en RAGASYS SISTEMAS.

En estos posts veremos cómo instalar y configurar Proxmox Datacenter Manager (PDM).

Proxmox Datacenter Manager es una solución de gestión centralizada de código abierto para infraestructuras distribuidas, con una interfaz web unificada, dónde podemos supervisar y controlar fácilmente múltiples servidores remotos Proxmox, consultar el estado y el rendimiento de un vistazo, y coordinar operaciones claves en clústeres y centros de datos.

Referencia Imagen

La topología utilizada sería la siguiente:

• Instalación y configuraciones iniciales de Proxmox Datacenter Manager (PDM).
• Agregar nodos Proxmox VE y Proxmox Backup Server a Proxmox Datacenter Manager.

Saludos y espero que os sea de ayuda

La entrada Instalación y configuración de Proxmox Datacenter Manager (PDM) se publicó primero en RAGASYS SISTEMAS.

En este post veremos una nueva funcionalidad que nos trae la nueva versión de Proxmox VE 9.1.1, que es soporte nativo para imágenes OCI (Open Container Initiative) en contenedores LXC.

• Antes de empezar a desplegar el contenedor LXC con la imagen OCI, sobre el datastore para Plantillas de CT, tenemos que descargar la plantilla que nos interese, para este despliegue vamos a descargarnos una plantilla de Grafana, pulsamos sobre Pull from OCI Registry:

• Sobre Reference, seleccionamos io/usuario/imagen si accedemos a docker hub podemos escoger cualquier imagen, sobre Etiqueta le indicamos la versión del contenedor y sobre Nombre del archivo le podemos indicar un nombre personalizado, si lo dejamos en blanco le asigna el nombre original del repositorio, Descargar:

• Vemos que la descarga ha sido correcta:

• Para empezar a crear el contenedor LXC con la imagen OCI, clicamos sobre, Crear CT:

• Sobre General, le indicamos el nodo, un ID, nombre, contraseña y una etiqueta, Siguiente:

• Sobre Plantilla, le indicamos el almacenamiento y la plantilla que hemos descargado, Siguiente:

• Sobre Discos, le indicamos el almacenamiento y tamaño de disco, Siguiente:

• Sobre CPU, le indicamos los parámetros que nos interesen para nuestro contenedor LXC, Siguiente:

• Sobre Memoria, le asignamos la cantidad que nos interesen para nuestro contenedor LXC, Siguiente:

• Sobre Red, le indicamos un nombre, que utilice el bridge que creamos anteriormente y le asignamos el direccionamiento IP de nuestra red, Siguiente:

• Sobre DNS, le indicamos el dominio y los DNS de nuestra infraestructura, Siguiente:

• Sobre Confirmar, nos muestra un resumen de todo lo que hemos configurado, le indicamos que lo inicie después de la creación, Finalizar:

• Vemos que se ha creado y se ha iniciado correctamente:

• Como podemos ver, aquí tenemos nuestro contenedor LXC con imagen OCI creado:

• Ahora en nuestro navegador, accedemos al panel web de la administración de grafana, http://192.168.7.115:3000 y vemos que ya tenemos una instancia de grafana disponible:

• Si hacemos un pct list sobre la shell de nuestro nodo proxmox, podemos ver los contenedores LXC que están corriendo:

• Con pct enter vmid podemos entrar al contenedor LXC:

• Con pct shutdown vmid podemos apagar al contenedor LXC:

• Con pct destroy vmid podemos eliminar el contenedor LXC:

• Con pct ? tenemos un listado de todos los comandos disponibles para trabajar con contenedores LXC:

Saludos y espero que os resulte de ayuda

La entrada Proxmox VE 9.1.1 – Contenedores LXC – Imágenes OCI se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo crear OSDs (Object Storage Device), pool de OSD y agregar almacenamiento al clúster Ceph, los OSDs son los discos físicos de cada nodo que se van a presentar al pool de OSD Ceph y poder así crear nuestros datastores para el clúster Ceph.

La topología utilizada sería la siguiente:

• Empezamos a crear el OSD para el nodo pvelab01 > Ceph > OSD > Crear OSD:

• Seleccionamos el disco y Crear:

• Una vez creado, damos a Recargar y vemos que ya nos muestra el OSD para el nodo pvelab01:

• Ahora creamos el OSD para el nodo pvelab02:

• Ahora creamos el OSD para el nodo pvelab03:

• Una vez creados los OSDs en cada uno de nuestros nodos, vamos a crear el pool de OSD Ceph y agregarlo o presentarlo como almacenamiento (datastore) al clúster Ceph, para ello, accedemos a pvelab01 > Ceph > Conjuntos > Crear:

• Le asignamos un nombre, marcamos el check Agregar como almacenamiento, y todo lo demás lo dejamos por defecto, Crear:

• Como podemos ver, aquí tenemos el pool de OSD Ceph creado:

• Si accedemos a los otros nodos del clúster, vemos que también nos muestra el pool de OSD Ceph:

• Si accedemos a Centro de datos > Almacenamiento, ya vemos que tenemos el datastore Ceph del tipo RBD operativo y listo para usarlo, también vemos como se ha agregado automáticamente a todos los nodos de nuestro clúster Ceph:

• Con todo esto, ya tendríamos configurado y operativo todo el almacenamiento compartido para nuestro clúster Ceph, si accedemos a cada nodo > Ceph, podemos ver el estado del nodo Ceph:

• Ahora vamos a desplegar una máquina virtual en este datastore Ceph, para ver como sus discos virtuales se replican de manera automática en todos los nodos del clúster, quedando almacenados estos discos virtuales en cada disco físico de cada nodo.
• Esta es la máquina que hemos desplegado en almacenamiento Ceph RBD:

• Al desplegar la máquina virtual sobre el nodo pvelab02, si accedemos al datastore ceph en cada uno de nuestros nodos del clúster, vemos que los discos virtuales de la máquina se han replicado en cada datastore de cada nodo del clúster Ceph:

Saludos y espero que os sea de ayuda

La entrada Crear OSDs, pool de OSD Ceph y agregar almacenamiento al clúster Ceph se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo agregar monitores a los nodos del clúster Ceph.

La topología utilizada sería la siguiente:

• Para empezar a agregar los monitores al cluster de Ceph, accedemos a nuestro nodo principal, pvelab01 > Ceph > Monitor > Crear, como vemos, el nodo pvelab01 ya está añadido desde la instalación inicial de Ceph, ahora debemos de agregar como monitores a los otros nodos del clúster:

• Como podemos ver, ya tenemos los tres nodos agregados al Monitor y como Manager está nuestro nodo pvelab01:

• Si accedemos a los otros nodos de nuestro clúster, ya nos lo debería mostrar todo igual que en el nodo maestro:

• En el siguiente post, veremos cómo crear OSDs, pool de OSD y agregar almacenamiento al clúster Ceph, tal y como nos indican los pasos a seguir al finalizar la instalación de Ceph.

Saludos y espero que os resulte de ayuda

La entrada Agregar monitores a los nodos del clúster Ceph se publicó primero en RAGASYS SISTEMAS.

En estos posts veremos cómo desplegar y configurar una infraestructura virtualizada con Proxmox VE 9.0, usando el Failover Clúster de Proxmox y la alta disponibilidad HA, vamos a usar tres nodos, pvelab01, pvelab02 y pvelab03, para el almacenamiento vamos a montar y configurar un pool local con Ceph, para entender que es y cómo funciona Ceph, digamos que es un híbrido entre el almacenamiento iSCSI y ZFS que hemos visto en los post anteriores, siendo almacenamiento local como en ZFS y compartido como en iSCSI, pero tiene la particularidad de que no tenemos que configurar la replicación como en ZFS, ya que al configurar Ceph los discos de las máquinas virtuales se replican de forma automática entre todos los almacenamientos Ceph del tipo RBD del clúster.

La topología utilizada sería la siguiente:

Estos post los vamos a dividir en las siguientes entradas:

• Creación y configuración Clúster de tres nodos en Proxmox VE 9.0
• Instalación y configuración de Ceph en Proxmox VE
• Agregar monitores a los nodos del clúster Ceph
• Crear OSDs, pool de OSD Ceph y agregar almacenamiento al clúster Ceph
• Migración en vivo de máquinas virtuales en un Cluster Proxmox con Ceph
• Configuración alta disponibilidad HA en un clúster Proxmox con Ceph

Saludos y espero que os resulte de ayuda

La entrada Desplegar y configurar un Cluster HA en Proxmox VE 9.0 con Ceph se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo agregar almacenamiento iSCSI multipath al clúster Proxmox VE 9.1.2 con configuraciones más avanzadas y mejor preparadas para trabajar en clúster, esto nos va a permitir:

• Definir parámetros avanzados, como round-robin, no_path_retry, rr_min_io…
• Asignar alias legibles a nuestras LUNs.
• Evitaremos que multipath intente agrupar discos locales con la opción de blacklists.
• Aseguraremos un comportamiento idéntico en todos los nodos de nuestro clúster.

Recordamos la topología:

• Para empezar, vamos a instalar en cada nodo los paquetes para el iniciador iSCSI y DM-Multipath, para ello, ejecutamos, apt install -y open-iscsi y apt install -y multipath-tools:

• Habilitamos e iniciamos los servicios para iscsid, ejecutamos, systemctl enable –now iscsid.service y systemctl enable –now open-iscsi.service:

• Habilitamos e iniciamos los servicios para multipathd, ejecutamos, systemctl enable –now multipathd.service:

• Comprobamos el estado de ambos servicios con systemctl status iscsid.service y systemctl status multipathd.service:

• Ahora vamos a ajustar conf, Proxmox recomienda reducir node.session.timeo.replacement_timeout = 15 para iSCSI, por defecto en 120s, lo pasamos a 15s, y para que la sesión sea persistente al arranque modificamos node.startup = automatic, para ello, editamos nano /etc/iscsi/iscsid.conf, esta modificación ayuda a que los timeouts de sesión sean más ágiles y evita esperas largas cuando tenemos fallos:

• Reiniciamos el servicio iscsid, systemctl restart iscsid.service y systemctl restart open-iscsi.service:

• Ahora vamos a descubrir los targets (IQNs) que nos ofrece nuestra cabina en cada IP/portal, esto no cambia ficheros manualmente, sino que guarda la información de esos targets en el directorio /etc/iscsi/nodes/ automáticamente, iscsiadm -m discovery -t st -p 10.10.2.4 y iscsiadm -m discovery -t st -p 10.10.3.4:

• Hacemos login en ambos portales, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -l y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -l, con esto conectamos los nodos pve a la cabina a través de las dos redes iSCSI:

• Para que el login sea persistente y se reconecte en cada reinicio, debemos de ejecutar, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -o update -n node.startup -v automatic y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -o update -n node.startup -v automatic:

• Comprobamos que ambos caminos están activos con, iscsiadm -m session -P3:

• Si accedemos a nuestra cabina SAN iSCSI, podemos ver, que ya tenemos los discos, en este caso, las LUNs conectadas:

• Ejecutamos en cada nodo, ls -l /dev/disk/by-path | grep 10.10 y como vemos la LUN0 tiene dos caminos, por 10.10.2.4 que aparece como /sdf y por 10.10.3.4 que aparece como /sdh, la LUN1 tiene dos caminos, por 10.10.2.4 que aparece como /sdg y por 10.10.3.4 que aparece como /sdi:

• Ahora, Multipath se basa en el WWID único de cada LUN, para obtenerlo ejecutamos:
• Para LUN0, /lib/udev/scsi_id -g -u -d /dev/sdf y /lib/udev/scsi_id -g -u -d /dev/sdh, ambos deben devolver el mismo WWID:

• Para LUN1, /lib/udev/scsi_id -g -u -d /dev/sdg y /lib/udev/scsi_id -g -u -d /dev/sdi, ambos deben devolver el mismo WWID:

• Añadimos el WWID de cada LUN para que multipath lo gestione.
• Para LUN0, multipath -a 360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, multipath -a 360003ff44dc75adc922dc286607e2e6f

• Recargamos multipath con multipath -r:

• Verificamos multipath con multipath -ll, esto significa que multipath creó un dispositivo /dev/dm-2 que representa a la LUN1, y dentro están los dos caminos activos (sdg y sdi), y otro dispositivo /dev/dm-1 que representa a la LUN0, y dentro están los dos caminos activos (sdf y sdh):

• Si ejecutamos ls -l /dev/mapper/ vemos lo siguiente:
• 360003ff44dc75adc922dc286607e2e6f, es el WWID de la LUN1.
• 360003ff44dc75adcbda106c1b22f4b5b, es el WWID de la LUN0.
• Ambos son enlaces simbólicos a los dispositivos multipath, /dev/dm-1 y /dev/dm-2
• control, es el dispositivo de control interno de multipath.

• Ahora vamos a crear el fichero /etc/multipath.conf en nuestros tres nodos con este contenido:

defaults {

user_friendly_names no

find_multipaths strict

path_selector «round-robin 0»

path_checker tur

rr_min_io 100

failback immediate

no_path_retry 12

}

blacklist {

devnode «^sda»

devnode «^sr0»

}

multipaths {

multipath {

wwid «360003ff44dc75adcbda106c1b22f4b5b»

alias «iscsi_saniscsipve_lun0»

}

multipath {

wwid «360003ff44dc75adc922dc286607e2e6f»

alias «iscsi_saniscsipve_lun1»

}

}

• Con este fichero configuramos:
• Round-robin activado
• Alias legibles (iscsi_saniscsipve_lun0 y iscsi_ saniscsipve _lun1)
• Parámetros ajustados para clusters (retry, failback, tur)
• Disco local sda y cdrom sr0 excluidos

• Ahora verificamos que el fichero /etc/multipath/wwids es exactamente igual en los tres nodos:

• Ahora ejecutamos estos tres comandos en los tres nodos:
• systemctl restart multipathd para recargar multipath.
• multipath -r para releer dispositivos multipath.
• multipath -ll para verificar.

• Con el comando ls -l /dev/mapper/iscsi_saniscsipve_lun* verificamos que existen los nuevos dispositivos:

• Ahora, la creación del Physical Volumen (PV) y Volume Group (VG), solo la vamos a hacer en un nodo, en este caso en el nodo 1, pvelab01.
• Para LUN0, pvcreate /dev/mapper/iscsi_saniscsipve_lun0 y vgcreate vg_iscsi0 /dev/mapper/iscsi_saniscsipve_lun0
• Para LUN1, pvcreate /dev/mapper/iscsi_saniscsipve_lun1 y vgcreate vg_iscsi1 /dev/mapper/iscsi_saniscsipve_lun1

• En los otros dos nodos ejecutamos, pvscan –cache y vgscan para que detecte el Physical Volumen (PV) y el Volume Group (VG):

• Si accedemos a todos los nodos > Discos > LVM, vemos que se han creado los Volume Group:

• Para terminar, accedemos a Centro de datos > Almacenamiento > Agregar > LVM:

• Sobre General, le indicamos el ID, Almacenamiento de base, Grupo del volumen, Contenido, Nodos, Activar, Compartido (importante activar para las migraciones en vivo), Agregar, para agregar la LUN0:

• Agregamos también la otra LUN1:

• Como podemos ver en, Centro de datos > Almacenamiento, tenemos los dos datastores añadidos:

• Aquí vemos, que los tres nodos, ya disponen del almacenamiento compartido por iSCSI y con Multipath:

Saludos y espero que os resulte de ayuda

La entrada Agregar almacenamiento iSCSI multipath al Clúster Proxmox VE 9.1.2 configuración avanzada se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo configurar la alta disponibilidad HA en un clúster Proxmox VE 9.0, con la HA configurada, cuando tengamos problemas en un nodo, las máquinas que están corriendo en ese nodo, se van a reiniciar en otro nodo disponible del clúster de forma automática.

Recordamos la topología:

• Para empezar a configurar HA accedemos a Centro de datos > HA, y lo primero que tenemos que ver que el quorum esté en estado OK:

• Sobre Centro de datos > HA, agregamos las máquinas virtuales que queramos proteger con HA:

• Le indicamos el ID de la máquina que queremos proteger, marcar el chek de Failback y en Estado de la solicitud le indicamos que la máquina se inicie en el host al que se migre, Agregar:

• Como podemos ver, ya tenemos estas dos máquinas protegidas con HA:

• Si accedemos al resumen de las máquinas, podemos ver, que el Estado de HA está en started:

• Ahora, para verificar que el HA está funcionando correctamente, vamos a simular que el nodo pvelab03 se nos ha caído, y que las máquinas virtuales protegidas por HA que están corriendo en ese nodo se migran a los otros nodos del cluster:

• Como vemos, el nodo pvelab03, ya no está disponible y las máquinas se han migrado e iniciado automáticamente en los otros nodos:

Saludos y espero que os resulte de ayuda

La entrada Configuración de alta disponibilidad HA en clúster Proxmox VE 9.0 con SAN iSCSI se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo migrar máquinas virtuales de forma online o en vivo en un clúster Proxmox VE 9.0, sin pérdida de servicios de estas máquinas.

Recordamos la topología:

• Vamos a migrar una máquina que está en el nodo 3 de nuestro cluster, pvelab03, al nodo 1, pvelab01, como podemos ver le tenemos un ping tirado, para verificar que no perdemos servicio, accedemos a la máquina y damos a Migrar:

• Como podemos ver, está en línea en el nodo pvelab03 y la vamos a migrar a pvelab01:

• Comienza la migración en vivo de la máquina, y vemos que se realiza correctamente:

• Ya la tenemos corriendo sobre el nodo pvelab01 y como nos indica el ping, no hemos perdido servicio en ningún momento:

Saludos y espero que os sea de ayuda

La entrada Migración de máquinas virtuales online o en vivo en clúster Proxmox VE 9.0 con SAN iSCSI se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo agregar almacenamiento iSCSI multipath al clúster Proxmox VE 9.0

Recordamos la topología:

• Para empezar, vamos a instalar en cada nodo los paquetes para el iniciador iSCSI y DM-Multipath, para ello, ejecutamos, apt install -y open-iscsi y apt install -y multipath-tools:

• Habilitamos e iniciamos los servicios para iscsid, ejecutamos, systemctl enable –now iscsid.service y systemctl enable –now open-iscsi.service:

• Habilitamos e iniciamos los servicios para multipathd, ejecutamos, systemctl enable –now multipathd.service:

• Comprobamos el estado de ambos servicios con systemctl status iscsid.service y systemctl status multipathd.service:

• Ahora vamos a ajustar /etc/iscsi/iscsid.conf, Proxmox recomienda reducir node.session.timeo.replacement_timeout = 15 para iSCSI, por defecto en 120s, lo pasamos a 15s, y para que la sesión sea persistente al arranque modificamos node.startup = automatic, para ello, editamos nano /etc/iscsi/iscsid.conf, esta modificación ayuda a que los timeouts de sesión sean más ágiles y evita esperas largas cuando tenemos fallos:

• Reiniciamos el servicio iscsid, systemctl restart iscsid.service y systemctl restart open-iscsi.service:

• Ahora vamos a descubrir los targets (IQNs) que nos ofrece nuestra cabina en cada IP/portal, esto no cambia ficheros manualmente, sino que guarda la información de esos targets en el directorio /etc/iscsi/nodes/ automáticamente, iscsiadm -m discovery -t st -p 10.10.2.4 y iscsiadm -m discovery -t st -p 10.10.3.4:

• Hacemos login en ambos portales, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -l y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -l, con esto conectamos los nodos pve a la cabina a través de las dos redes iSCSI:

• Para que el login sea persistente y se reconecte en cada reinicio, debemos de ejecutar, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -o update -n node.startup -v automatic y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -o update -n node.startup -v automatic:

• Comprobamos que ambos caminos están activos con, iscsiadm -m session -P3:

• Si accedemos a nuestra cabina SAN iSCSI, podemos ver, que ya tenemos los discos, en este caso, las LUNs conectadas:

• Ejecutamos en cada nodo, ls -l /dev/disk/by-path | grep 10.10 y como vemos la LUN0 tiene dos caminos, por 10.10.2.4 que aparece como /sdc y por 10.10.3.4 que aparece como /sde, la LUN1 tiene dos caminos, por 10.10.2.4 que aparece como /sdd y por 10.10.3.4 que aparece como /sdf:

• Ahora, Multipath se basa en el WWID único de cada LUN, para obtenerlo ejecutamos:
• Para LUN0, /lib/udev/scsi_id -g -u -d /dev/sdc y /lib/udev/scsi_id -g -u -d /dev/sde, ambos deben devolver el mismo WWID:

• Para LUN1, /lib/udev/scsi_id -g -u -d /dev/sdd y /lib/udev/scsi_id -g -u -d /dev/sdf, ambos deben devolver el mismo WWID:

• Añadimos el WWID de cada LUN para que multipath lo gestione.
• Para LUN0, multipath -a 360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, multipath -a 360003ff44dc75adc922dc286607e2e6f

• Recargamos multipath con multipath -r:

• Verificamos multipath con multipath -ll, esto significa que multipath creó un dispositivo /dev/dm-0 que representa a la LUN0, y dentro están los dos caminos activos (sdc y sde), y otro dispositivo /dev/dm-1 que representa a la LUN1, y dentro están los dos caminos activos (sdd y sdf):

• Si ejecutamos ls -l /dev/mapper/ vemos lo siguiente:
• 360003ff44dc75adc922dc286607e2e6f, es el WWID de la LUN1.
• 360003ff44dc75adcbda106c1b22f4b5b, es el WWID de la LUN0.
• Ambos son enlaces simbólicos a los dispositivos multipath , /dev/dm-0 y /dev/dm-1
• control, es el dispositivo de control interno de multipath.

• Ahora, la creación del Physical Volumen (PV) y Volume Group (VG), solo la vamos a hacer en un nodo, en este caso en el nodo 1, pvelab01.
• Para LUN0, pvcreate /dev/mapper/360003ff44dc75adcbda106c1b22f4b5b y vgcreate vg_iscsi0 /dev/mapper/360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, pvcreate /dev/mapper/360003ff44dc75adc922dc286607e2e6f y vgcreate vg_iscsi1 /dev/mapper/360003ff44dc75adc922dc286607e2e6f

• Si accedemos a todos los nodos > Discos > LVM, vemos que se han creado los Volume Group:

• Para terminar, accedemos a Centro de datos > Almacenamiento > Agregar > LVM:

• Sobre General, le indicamos el ID, Almacenamiento de base, Grupo del volumen, Contenido, Nodos, Activar, Compartido (importante activar para las migraciones en vivo), Agregar, para agregar la LUN0:

• Agregamos también la otra LUN1:

• Como podemos ver en, Centro de datos > Almacenamiento, tenemos los dos datastores añadidos:

• Aquí vemos, que los tres nodos, ya disponen del almacenamiento compartido por iSCSI y con Multipath:

Saludos y espero que os sea de ayuda

La entrada Agregar almacenamiento iSCSI multipath al Clúster Proxmox VE 9.0 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo crear y configurar un clúster de 3 nodos en Proxmox VE 9.0

Recordamos la topología:

• Para empezar a crear el clúster, vamos a acceder a nuestro nodo1, pvelab01, sobre Centro de datos > Cluster > Crear cluster:

• Le indicamos un nombre para el cluster, y debemos asignarle dos interfaces de red, la primera es la de la red de management y la segunda es la dedicada para el clúster, Crear:

• Vemos que se crea el clúster y se añade el nodo correctamente, y ya tenemos nuestro primer nodo en el clúster:

• Ahora vamos a unir los otros dos nodos al clúster, para ello, necesitamos la información de unión, que nos la da este primer nodo:

• Accedemos al segundo nodo, pvelab02, sobre Centro de datos > Cluster > Unirse al cluster y pegamos la información que copiamos del clúster creado sobre el nodo 1, le indicamos la IP del nodo 1, la contraseña de root, la huella digital, y configuramos la red del clúster al igual que hicimos en el nodo 1, Unir al clúster:

• Accedemos al tercer nodo, pvelab03, sobre Centro de datos > Cluster > Unirse al cluster y pegamos la información que copiamos del clúster creado sobre el nodo 1, le indicamos la IP del nodo 1, la contraseña de root, la huella digital, y configuramos la red del clúster al igual que hicimos en el nodo 1 y en el nodo 2, Unir al clúster:

• Ahora sobre el nodo 1, pvelab01 > Centro de datos > Cluster, podemos ver, que ya tenemos el clúster de proxmox creado y configurado con tres nodos:

• Sobre Centro de datos > Resumen, podemos ver, un resumen del estado de nuestro clúster:

• Ahora desde cualquiera de los nodos del clúster, tendremos acceso:

Saludos y espero que os resulte de ayuda

La entrada Creación y configuración clúster de 3 nodos en Proxmox VE 9.0 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo preparar los servidores Proxmox VE 9.0 y la cabina SAN iSCSI para nuestra infraestructura virtualizada con Proxmox en un Cluster HA.

Recordamos la topología:

• Vamos a empezar viendo, como tenemos configurado nuestros tres nodos de proxmox, para la instalación, configuración de repositorios para las actualizaciones, configuración de networking, administración de usuarios, grupos, roles y permisos, conexión con Active Directory y unión a un dominio de Active Directory, hemos seguido los post anteriores en los que hemos hablado de todo esto, lo único que se ha ampliado es la parte de networking, que la vamos a explicar ahora.
• Como podemos ver tenemos estos tres nodos proxmox:

• La configuración de networking, es la siguiente en los tres nodos, como podemos ver, tenemos un bond (bond0) en modo balance-alb que utiliza dos interfaces de red (ens192 y ens224), este bond es el que utilizamos en el Linux Bridge (vmbr0) para Management y las máquinas virtuales, tenemos una interface de red dedicada a la comunicación interna de los nodos (ens256), una interface de red dedicada para iSCSIA (ens161) y otra interface de red dedicada para iSCSIB (ens193), en estas redes iSCSI configuraremos el multipath:

• Para la cabina SAN iSCSI hemos montado un Windows Server 2025 Standard y le hemos desplegado el rol de Servidor de destino iSCSI, en este link de este mismo blog podéis ver como se despliega y configura:

• Como podemos ver, hemos configurado dos LUNs de 500 GB cada una, sobre el mismo target o portal iqn, y le hemos añadido las IPs de los tres nodos de proxmox para iSCSIA y iSCSIB:

Saludos y espero que os sea de ayuda

La entrada Preparación Servidores Proxmox VE 9.0 y Cabina SAN iSCSI se publicó primero en RAGASYS SISTEMAS.

En estos posts veremos cómo desplegar y configurar una infraestructura virtualizada con Proxmox VE 9.0, usando el Failover Clúster de Proxmox y la alta disponibilidad HA, vamos a usar tres nodos, pvelab01, pvelab02 y pvelab03, para el almacenamiento vamos a montar y configurar una SAN iSCSI.

La topología utilizada sería la siguiente:

Estos post los vamos a dividir en las siguientes entradas:

• Preparación Servidores Proxmox VE 9.0 y Cabina SAN iSCSI
• Creación y configuración Clúster de tres nodos en Proxmox VE 9.0
• Agregar almacenamiento iSCSI multipath al Clúster Proxmox VE 9.0
• Agregar almacenamiento iSCSI multipath al Clúster Proxmox VE 9.1.2 configuración avanzada
• Migración de máquinas virtuales online o en vivo en Clúster Proxmox VE 9.0 con SAN iSCSI
• Configuración de alta disponibilidad HA en Clúster Proxmox VE 9.0 con SAN iSCSI

Saludos.

La entrada Desplegar y configurar un Cluster HA en Proxmox VE 9.0 con SAN iSCSI se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo desplegar un contenedor LXC sobre nuestro nodo Proxmox VE 9.0.

• Antes de empezar a desplegar el contenedor LXC, sobre el datastore para Plantillas de CT, tenemos que descargar la plantilla que nos interese, para este despliegue vamos a descargarnos una plantilla de Ubuntu 24.04 standard:

• Como vemos, la descarga ha sido correcta:

• Para empezar a crear el contenedor LXC, clicamos sobre, Crear CT:

• Sobre General, le indicamos el nodo, un ID, nombre, contraseña y una etiqueta, Siguiente:

• Sobre Plantilla, le indicamos el almacenamiento y la plantilla que hemos descargado, Siguiente:

• Sobre Discos, le indicamos el almacenamiento y tamaño de disco, Siguiente:

• Sobre CPU, le indicamos los parámetros que nos interesen para nuestro contenedor LXC, Siguiente:

• Sobre Memoria, le asignamos la cantidad que nos interesen para nuestro contenedor LXC, Siguiente:

• Sobre Red, le indicamos un nombre, que utilice el bridge que creamos anteriormente y le asignamos el direccionamiento IP de nuestra red, Siguiente:

• Sobre DNS, le indicamos el dominio y los DNS de nuestra infraestructura, Siguiente:

• Sobre Confirmar, nos muestra un resumen de todo lo que hemos configurado, Finalizar:

• Vemos que se ha creado correctamente:

• Como podemos ver, aquí tenemos nuestro contenedor LXC creado:

• Si accedemos a Almacenamiento > DTS01VMCT > Volúmenes de CT, podemos ver el disco del contenedor que hemos creado:

• Volvemos al contenedor LXC, abrimos la Consola y lo iniciamos:

• Como podemos ver, ya tenemos nuestro contenedor LXC con Ubuntu 24.04 LTS standard desplegado sobre Proxmox VE 9.0:

• Para el tema de los snapshots y respaldos, funciona exactamente igual que ya explicamos para las máquinas virtuales:

Saludos y espero que os resulte de ayuda

La entrada Despliegue de Contenedor LXC en Proxmox VE 9.0 se publicó primero en RAGASYS SISTEMAS.