One place for hosting & domains

      Cómo monitorizar el estado del servidor con Checkmk en Ubuntu 18.04


      El autor seleccionó a Open Internet/Free Speech Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Cómo administrador del sistema, es una buena práctica conocer el estado actual de su infraestructura y servicios. Idealmente, querrá darse cuenta de los discos que fallan o los tiempos de inactividad de la aplicación antes de que lo hagan sus usuarios. Las herramientas de monitorización como Checkmk pueden ayudar a los administradores a detectar estos problemas y a mantener los servidores en perfecto estado.

      Generalmente, el software de monitorización puede realizar un seguimiento del hardware de sus servidores, el tiempo de actividad y los estados de servicio, y puede presentar alertas si algo va mal. En un escenario muy básico, un sistema de monitorización le alertaría si algún servicio falla. En uno más robusto, las notificaciones llegarían poco después de que surja cualquier señal sospechosa, como un mayor uso de la memoria o una cantidad anormal de conexiones TCP.

      Existen muchas soluciones de monitorización disponibles que ofrecen varios grados de complejidad y conjuntos de funciones, tanto gratuitas como comerciales. En muchos casos, la instalación, configuración y gestión de estas herramientas es difícil y requieren mucho tiempo.

      Checkmk, sin embargo, es una solución de monitorización robusta y sencilla de instalar. Es un paquete de software autónomo que combina Nagios (un servicio de alertas popular y de código abierto) con complementos para recopilar, monitorizar y realizar gráficos de los datos. También cuenta con la interfaz web de Checkmk, una herramienta integral que aborda muchas de las deficiencias de Nagio. Ofrece un panel de control fácil de usar, un sistema de notificaciones completo y un repositorio de agentes de monitorización fáciles de instalar para muchas distribuciones Linux. Si no fuese por la interfaz web de Checkmk, tendríamos que utilizar diferentes vistas para diferentes tareas y no sería posible configurar todas esas funciones sin recurrir a amplias modificaciones de archivos.

      En esta guía, configuraremos Checkmk en un servidor Ubuntu 18.04 y monitorizaremos dos hosts independientes. Monitorizaremos el servidor Ubuntu también como servidor CentOS 7 independiente, pero podríamos usar el mismo enfoque para añadir cualquier cantidad de hosts adicionales a nuestra configuración de monitorización.

      Requisitos previos

      Paso 1: Instalar Checkmk en Ubuntu

      Para usar nuestro sitio de monitorización, primero debemos instalar Checkmk en el servidor Ubuntu. Esto nos proporcionará las herramientas que necesitamos. Checkmk ofrece archivos de paquete Ubuntu listos para usar que podemos utilizar para instalar nuestro paquete de software.

      Primero, vamos a utilizar la lista de paquetes para tener la versión más reciente de los listados del repositorio:

      Para examinar los paquetes, podemos ir al sitio de listado de paquetes. En el menú de la página puede seleccionarse Ubuntu 18.04 entre otros.

      Ahora, descargue el paquete:

      • wget https://checkmk.com/support/1.6.0p8/check-mk-raw-1.6.0p8_0.bionic_amd64.deb

      A continuación, instale el paquete recién descargado:

      • sudo apt install -y ./check-mk-raw-1.6.0p8_0.bionic_amd64.deb

      Este comando instalará el paquete Checkmk junto con todas las dependencias necesarias, incluyendo el servidor web Apache que se usa para proporcionar acceso web a la interfaz de monitorización.

      Tras completarse la instalación, ahora podemos acceder al comando omd. Pruébelo:

      Este comando omd generará el siguiente resultado:

      Output

      Usage (called as root): omd help Show general help . . . General Options: -V <version> set specific version, useful in combination with update/create omd COMMAND -h, --help show available options of COMMAND

      El comando omd puede gestionar todas las instancias Checkmk en nuestro servidor. Puede iniciar y detener todos los servicios de monitorización a la vez, y podremos utilizarlo para crear nuestra instancia Checkmk. Primero, sin embargo, tenemos que actualizar los ajustes de nuestro firewall para permitir el acceso externo a los puertos web predeterminados.

      Paso 2: Configurar el firewall

      Antes de poder trabajar con Checkmk, es necesario permitir el acceso externo al servidor web en la configuración del firewall. Asumiendo que siguió los pasos de configuración del firewall en los requisitos previos, tendrá un firewall UFW configurado para restringir el acceso a su servidor.

      Durante la instalación, Apache se registra con UFW para proporcionar una forma sencilla de habilitar o deshabilitar el acceso a Apache a través del firewall.

      Para permitir el acceso a Apache, utilice el siguiente comando:

      Ahora, verifique los cambios:

      Verá que Apache está listado entre los servicios permitidos:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Esto nos permitirá acceder a la interfaz web de Checkmk.

      En el siguiente paso, crearemos la primera instancia de monitorización de Checkmk.

      Paso 3: Crear una instancia de monitorización de Checkmk

      Checkmk utiliza el concepto de instancias, o instalaciones individuales, para aislar múltiples copias de Checkmk en un servidor. En la mayoría de los casos, una única copia de Checkmk es suficiente y así es como configuraremos el software en esta guía.

      Primero, debemos proporcionar un nombre a nuestra nueva instancia, y usaremos monitoring en este texto Para crear la instancia, escriba:

      • sudo omd create monitoring

      La herramienta omd configurará todo automáticamente. El comando debe tener un aspecto similar al siguiente:

      Output

      Adding /opt/omd/sites/monitoring/tmp to /etc/fstab. Creating temporary filesystem /omd/sites/monitoring/tmp...OK Restarting Apache...OK Created new site monitoring with version 1.6.0p8.cre. The site can be started with omd start monitoring. The default web UI is available at http://your_ubuntu_server/monitoring/ The admin user for the web applications is cmkadmin with password: your-default-password (It can be changed with 'htpasswd -m ~/etc/htpasswd cmkadmin' as site user.) Please do a su - monitoring for administration of this site.

      En este resultado, se resaltarán la dirección URL, nombre predeterminado del usuario y contraseña para acceder a nuestra interfaz de monitorización. La instancia se crea ahora, pero aún debe iniciarse. Para iniciar la instancia, escriba:

      • sudo omd start monitoring

      Ahora, todas las herramientas y servicios necesarios se iniciarán a la vez. Al final, veremos un resultado que verifica que todos nuestros servicios se han iniciado correctamente:

      Output

      Starting mkeventd...OK Starting rrdcached...OK Starting npcd...OK Starting nagios...OK Starting apache...OK Initializing Crontab...OK

      La instancia está lista.

      Para acceder a la instancia Checkmk, abra http://your_ubuntu_server_ip/monitoring/ en el navegador web. Se le solicitará una contraseña. Utilice las credenciales predeterminadas impresas previamente en la pantalla; cambiaremos estos valores predeterminados más adelante.

      La pantalla de Checkmk se abre con un panel de control, que muestra todos nuestros servicios y los estados del servidor en listas, y utiliza gráficos prácticos que se parecen a la Tierra. Justo después de la instalación, estos están vacíos, pero pronto se mostrarán estados para nuestros servicios y sistemas.

      Panel de control en blanco de Checkmk

      En el siguiente paso, cambiaremos la contraseña predeterminada para proteger el sitio usando esta interfaz.

      Paso 4: Cambiar su contraseña administrativa

      Durante la instalación, Checkmk genera una contraseña aleatoria para el usuario administrativo cmkadmin. Esta contraseña debe cambiarse tras la instalación, y como tal, a menudo es corta y no muy segura. Podemos cambiar esto a través de la interfaz web.

      Primero, abra la página Users desde el menú WATO – Configuration a la izquierda. La lista mostrará todos los usuarios que actualmente tiene acceso al sitio de Checkmk. En una nueva instalación, listará solo dos usuarios. El primero, automation, está destinado a ser usado con herramientas automatizadas; el segundo es el usuario cmkadmin, que usamos para iniciar sesión en el sitio.

      Lista de usuarios Checkmk

      Haga clic en el icono de lápiz junto al usuario cmkadmin para cambiar sus detalles, incluyendo la contraseña.

      Formulario de edición para el usuario admin de Checkmk

      Actualice la contraseña, añada un correo electrónico de administrador y realice cualquier otro cambio que quiera.

      Tras guardar los cambios, nos solicitará que iniciemos sesión de nuevo con nuestras nuevas credenciales. Haga esto y vuelva al panel de control, donde hay una cosa más que debemos hacer para aplicar por completo nuestra nueva configuración.

      De nuevo, abra la página Users desde el menú WATO – Configuration a la izquierda. El botón naranja en la esquina superior derecha etiquetado como 1 Change nos indica que hemos realizado algunos cambios a la configuración de Checkmk, y que debemos guardarlos y activarlos. Esto sucederá cada vez que cambiemos la configuración de nuestro sistema de monitorización, no solo tras editar las credenciales del usuario. Para guardar y activar los cambios pendientes, debemos hacer clic en este botón y aceptar activar los cambios enumerados usando la opción Activate affected en la siguiente pantalla.

      Lista de usuarios de Checkmk tras las modificaciones Activar la pantalla de configuración en los cambios de configuración Cambios de configuración activados correctamente

      Tras activar los cambios los datos del nuevo usuario se escriben en los archivos de configuración serán usados por todos los componentes del sistema. Checkmk notifica automáticamente a los componentes individuales del sistema de monitorización, recargándolos cuando sea necesario y administrando todos los archivos de configuración necesarios.

      La instalación de Chekmk ahora está lista para usarse. En el siguiente paso, añadiremos el primer host a nuestro sistema de monitorización.

      Paso 5: Monitorizar el primer host

      Ahora estamos listos para monitorizar el primer host. Para conseguir esto, primero instalaremos check-mk-agent en el servidor Ubuntu. A continuación, restringiremos el acceso a los datos de monitorización usando xinetd.

      Los componentes instalados con Checkmk se encargan de recibir, almacenar y presentar la información de monitorización. No proporcionan información en sí mismos.

      Para recopilar datos reales, usaremos el agente de Checkmk. Diseñado específicamente para este trabajo, el agente de Checkmk es capaz de monitorizar todos los componentes vitales del sistema a la vez y de reportar esa información a la instancia de Checkmk.

      Instalar el agente

      El primer host que monitorizaremos será your_ubuntu_server, el servidor sobre el cual hemos instalado la instancia Checkmk.

      Para comenzar, debemos instalar el agente de Checkmk. Los paquetes para todas las distribuciones principales, incluyendo Ubuntu, están disponibles directamente desde la interfaz web. Abra la página Monitoring Agents desde el menú WATO – Configuration a la izquierda. Verá las descargas de agente disponibles con los paquetes más populares bajo la primera sección, etiquetada como Packaged agents.

      Lista de agentes de monitorización empaquetados disponibles

      El paquete check-mk-agent_1.6.0p8-18_all.ded es el adecuado para las distribuciones basadas en Debian, incluyendo Ubuntu. Copie el enlace de descarga para ese paquete desde el navegador web y utilice esa dirección para descargar el paquete.

      • wget http://your_ubuntu_server_ip/monitoring/check_mk/agents/check-mk-agent_1.6.0p8-1_all.deb

      Tras su descarga, instale el paquete:

      • apt install -y ./check-mk-agent_1.6.0p8-1_all.deb

      Ahora, verifique que el agente se ha instalado correctamente:

      El comando generará un texto muy largo que parece un texto sin sentido, pero combina toda la información vital sobre el sistema en un solo lugar.

      Output

      <<<check_mk>>> Version: 1.6.0p8 AgentOS: linux . . . ["monitoring"] <<<job>>> <<<local>>>

      Checkmk utiliza el resultado de este comando para recopilar datos de esto desde los hosts monitorizados. Ahora, restringiremos el acceso a los datos de monitorización usando xinetd.

      Restringir el acceso a los datos de monitorización utilizando xinetd

      Por defecto, los datos de check_mk_agent se presentan usando xinetd, un mecanismo que genera datos sobre un cierto puerto de red tras acceder a él. Esto significa que podemos acceder a chek_mk_agent usando telnet al puerto 6556 (el puerto predeterminado para Checkmk) desde cualquier otro equipo en Internet a menos que la configuración de nuestro firewall no lo permita.

      No es una buena política de seguridad publicar información vital sobre los servidores a nadie en Internet. Solo deberíamos permitir a los hosts que ejecuten Checkmk y estén bajo supervisión acceder a estos datos, de forma que solo nuestro sistema de monitorización pueda recopilarlos.

      Si siguió el tutorial de configuración inicial del servidor, incluyendo los pasos sobre cómo configurar un firewall, el acceso al agente Checkmk está bloqueado por defecto. Sin embargo, es una buena práctica aplicar estas restricciones de acceso directamente en la configuración del servicio, y no depender únicamente de un firewall para su protección.

      Para restringir el acceso a los datos del agente, tenemos que editar el archivo de configuración en /etc/xinetd.d/check_mk. Abra el archivo de configuración en su editor favorito. Para utilizar nano, escriba:

      • sudo nano /etc/xinetd.d/check_mk

      Localice esta sección:

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      #only_from      = 127.0.0.1 10.0.20.1 10.0.20.2
      . . .
      

      El ajuste only_from se encarga de restringir el acceso a ciertas direcciones IP. Debido a que ahora estamos trabajando en monitorizar el mismo servidor sobre el que Checkmk se está ejecutando, está bien permitir que localhost se conecte. Elimine y actualice el ajuste de configuración a:

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      only_from      = 127.0.0.1
      . . .
      

      Guarde el archivo y ciérrelo.

      El daemon xinetd debe reiniciarse para que los cambios surtan efecto. Hágalo ahora:

      • sudo systemctl restart xinetd

      Ahora, nuestro agente está en funcionamiento y restringido para aceptar solo las conexiones locales. Podemos proceder a configurar la monitorización para ese host usando Checkmk.

      Configurar el host en la interfaz web de Checkmk

      Primero, para añadir un nuevo host a monitorizar tenemos que ir al menú Hosts en el menú WATO – Configuration a la izquierda. Desde aquí, haga clic en Create new host. Se nos solicitará cierta información sobre el host.

      Creación de un nuevo host en Checkmk

      El Hostname es el nombre familiar que Checkmk usará para la monitorización. Puede ser un nombre de dominio completamente cualificado, pero no es necesario. En este ejemplo, llamaremos al host monitoring, igual que el nombre de la instancia Checkmk. Debido a que monitoring no se resuelve a nuestra dirección IP, también debemos proporcionar la dirección IP de nuestro servidor. Y ya que estamos monitorizando el host local, la IP será simplemente 127.0.0.1. Seleccione la casilla IPv4 Address para habilitar la entrada manual de la IP e introduzca el valor en el campo de texto.

      La configuración predeterminada de la sección Data Sources depende del agente Checkmk para proporcionar los datos de monitorización, lo que está bien. El ajuste Networking Segment se usa para indicar los hosts en las redes remotas, que se caracterizan por una mayor latencia esperada, lo cual no es una señal de mal funcionamiento. Ya que este es un host local, el ajuste predeterminado también está bien.

      Para guardar el host y configurar qué servicios se monitorizarán, haga clic en el botón Save & go to services.

      Lista de servicios disponibles para monitorizar

      Checkmk realizará un inventario automático. Eso significa que recopilará el resultado del agente y lo descifrará para saber qué tipos de servicios puede monitorizar. Todos los servicios disponibles para la monitorización estarán en la lista, incluyendo carga de CPU, uso de memoria y espacio libre en los discos.

      Para habilitar la monitorización de todos los servicios descubiertos, debemos hacer clic en el botón Monitor bajo la sección Undecided services (currently not monitored). Esto actualizará la página, pero ahora todos los servicios se listarán bajo la sección Monitored services, informándonos de que están siendo monitorizados.

      Igual que cuando cambiamos nuestra contraseña de usuario, estos nuevos cambios deben guardarse y activarse antes de que estén activos. Pulse el botón 2 changes y acepte lo cambios usando el botón Activate affected. Tras esto, la monitorización del host estará lista.

      Ahora está listo para trabajar con los datos de su servidor. Eche un vistazo al panel de control principal utilizando el elemento de menú Overview/Main Overview (Información/Información principal) a la izquierda.

      Trabajar con los datos de la monitorización

      Ahora, vamos a ver el panel de control principal usando el menú Overview/Main Overview a la izquierda:

      Panel de control de la monitorización con todos los servicios en buen estado

      La esfera de la Tierra está completamente verde y la tabla dice que un host está activo sin problemas. Podemos ver la lista completa de hosts, que ahora consta de un único host, en la vista Hosts/All hosts (usando el menú de la izquierda).

      Lista de los hosts con todos los servicios en buen estado

      Ahí veremos cuántos servicios están en buen estado (en verde), cuántos están fallando y cuántos deben comprobarse aún. Tras hacer clic en el nombre del host, podremos ver la lista de todos los servicios con sus estados completos y sus Perf-O-Meters. El Perf-O-Meter muestra el rendimiento de un único servicio en relación con lo que Checkmk considera que es un buen estado.

      Detalles del estado de un servicio de host

      Todos los servicios que devuelven datos que pueden ponerse en un gráfico mostrarán un icono de gráfico junto a su nombre. Podemos utilizar ese ícono para obtener acceso a los gráficos asociados con el servicio. Ya que la monitorización del host es nueva, los gráficos no tienen casi nada, pero, tras algún tiempo, los gráficos proporcionarán información valiosa sobre cómo cambia el rendimiento de nuestro servicio a lo largo del tiempo.

      Gráficos que representan la carga en la CPU del servidor

      Cuando cualquiera de estos servicios falle o se recupere, la información se mostrará en el panel de control. Para los servicios que fallan, se mostrará un error en rojo, y el problema también estará visible en el gráfico de la Tierra.

      Panel de control con un host con problemas

      Tras la recuperación, todo se mostrarán en verde, lo que indica un buen funcionamiento, pero el registro de eventos de la derecha contendrá información sobre fallos anteriores.

      Panel de control con un host recuperado tras presentar problemas

      Ahora que hemos explorado el panel de control, vamos a añadir un segundo host a nuestra instancia de monitorización.

      Paso 6: Monitorizar un segundo host CentOS

      La monitorización es realmente útil cuando tiene varios hosts. Ahora añadiremos un segundo servidor a nuestra instancia Checkmk, esta vez ejecutando CentOS 7.

      Al igual que con nuestro servidor Ubuntu, es necesario instalar el agente Checkmk para recopilar datos de monitorización en CentOS. Esta vez, sin embargo, necesitaremos un paquete rpm desde la página Monitoring Agentes en la interfaz web, llamado check-mk-agent-1.6.0p8-1.noarch.rpm.

      Primero, sin embargo, debemos instalar xinetd, que por defecto no está disponible en la instalación CentOS. Xinetd, como recordará, es un daemon responsable de poner a disposición sobre la red los datos de monitorización proporcionados por check_mk_agent.

      En su servidor CentOS, primero instale xinetd:

      • sudo yum install -y xinetd

      Ahora podemos descargar e instalar el paquete del agente de monitorización necesario para nuestro servidor CentOS:

      • sudo yum install -y http://your_ubuntu_server_ip/monitoring/check_mk/agents/check-mk-agent-1.6.0p8-1.noarch.rpm

      Igual que antes, podemos verificar que el agente funciona correctamente ejecutando check_mk_agent:

      El resultado será similar al del servidor Ubuntu. Ahora, restringiremos el acceso al agente.

      Restringir el acceso

      Esta vez no monitorizaremos un host local, de forma que xinetd debe permitir las conexiones que provienen del servidor Ubuntu, donde Checkmk está instalado, para recopilar los datos. Para permitir esto, primero abra su archivo de configuración:

      • sudo vi /etc/xinetd.d/check_mk

      Aquí verá la configuración para su servicio check_mk, especificando cómo se puede acceder al agente Checkmk a través del daemon xinetd. Busque las siguientes dos líneas comentadas:

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      #only_from      = 127.0.0.1 10.0.20.1 10.0.20.2
      . . .
      

      Ahora, elimine la segunda línea y sustituya las direcciones IP locales con your_ubuntu_server_ip:

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      only_from      = your_ubuntu_server_ip
      . . .
      

      Guarde y salga del archivo escribiendo :x y luego ENTER. Reinicie el servicio xinetd usando:

      • sudo systemctl restart xinetd

      Ahora podemos configurar Checkmk para que monitorice nuestro host CentOS 7.

      Configurar un nuevo host en Checkmk

      Para añadir hosts adicionales a Checkmk, usamos el menú Hosts como hicimos antes. Esta vez, llamaremos al host centos, configuraremos su dirección IP, y seleccionaremos WAN (high-latency) bajo la casilla de selección Networking Segment, ya que el host está en otra red. Si omitimos esto y lo dejamos como local, Checkmk pronto nos alertará de que el host está desconectado, ya que esperaría que respondiese a las consultas del agente mucho más rápido de lo que es posible por Internet.

      Crear la pantalla de configuración del segundo host

      Haga clic en Save & go to services, lo que mostrará los servicios disponibles para monitorizar sobre el servidor CentOS. La lista será muy similar a la del primer host. De nuevo, esta vez debemos hacer clic en Monitor y, luego, activar los cambios utilizando el botón naranja en la esquina superior izquierda.

      Tras activar los cambios, podemos verificar que el host está siendo monitorizado en la página All hosts. Vaya allí. Ahora estarán visibles dos hosts, monitoring y centos.

      Lista de hosts con dos hosts monitorizados

      Ahora está monitorizando un servidor Ubuntu y un servidor CentOS con Checkmk. Es posible monitorizar aún más hosts. De hecho, no hay un límite aparte del rendimiento del servidor, que no debería ser un problema hasta que su número de hosts sea de cientos. Además, el procedimiento es el mismo para cualquier otro host. Los agentes Checkmk en los paquetes deb y rpm funcionan en Ubuntu, CentOS y en la mayoría de las otras distribuciones Linux.

      Conclusión

      En esta guía hemos configurado dos servidores con dos distribuciones Linux diferentes: Ubuntu y CentOS. A continuación, instalamos y configuramos Checkmk para monitorizar ambos servidores, y exploramos la potente interfaz web de Checkmk.

      Checkmk permite configurar fácilmente un sistema de monitorización completo y versátil, que empaqueta todo el difícil trabajo de la configuración manual en una interfaz web fácil de usar con múltiples opciones y funciones. Con estas herramientas es posible monitorizar múltiples hosts; configurar correo electrónico, SMS o notificaciones push cuando se produzcan problemas; configurar comprobaciones adicionales para más servicios; monitorizar la accesibilidad y el rendimiento, etcétera.

      Para obtener más información sobre Checkmk, asegúrese de visitar la documentación oficial.



      Source link

      Configuración inicial del servidor con Ubuntu 20.04


      Introducción

      Cuando crea por primera vez un nuevo servidor Ubuntu 20.04, debe realizar algunos pasos de configuración importantes como parte de la configuración básica. Estos pasos aumentarán la seguridad y utilidad de su servidor, y le brindará una base sólida para las siguientes acciones.

      Paso 1: Iniciar sesión como root

      Para iniciar sesión en su servidor, deberá conocer la dirección IP pública de este. También necesitará la contraseña o, si instaló una clave SSH para la autenticación, la clave privada para la cuenta del root user. Si aún no inició sesión en su servidor, quizá desee seguir nuestra guía sobre cómo establecer conexión con Droplets mediante SSH, que cubre con detalle este proceso.

      Si aún no está conectado con su servidor, inicie sesión como root user usando ahora el siguiente comando (sustituya la parte resaltada del comando por la dirección IP pública de su servidor):

      Acepte la advertencia sobre la autenticidad del host si aparece. Si utiliza la autenticación con contraseña, proporcione su contraseña root para iniciar sesión. Si utiliza una clave SSH protegida con una frase de contraseña, es posible que se le solicite ingresar esta última la primera vez que utilice la clave en cada sesión. Si es la primera vez que inicia sesión en el servidor con una contraseña, puede que también se le solicite cambiar la contraseña root.

      Acerca de root

      El root user es el usuario administrativo en un entorno Linux y tiene privilegios muy amplios. Debido a estos privilegios mayores de la cuenta root, no se recomienda usarla de manera regular. Esto se debe a que parte del poder inherente de la cuenta root es la capacidad de realizar cambios muy destructivos, incluso por accidente.

      El siguiente paso es configurar una nueva cuenta de usuario con menos privilegios para el uso cotidiano. Más tarde, le enseñaremos cómo obtener más privilegios solo durante los momentos en que los necesite.

      Paso 2: Crear un nuevo usuario

      Una vez que haya iniciado sesión como root, estaremos preparados para añadir la nueva cuenta de usuario. En el futuro, iniciaremos sesión con esta nueva cuenta en vez de con root.

      En este ejemplo se crea un nuevo usuario llamado sammy, pero debe sustituirlo por cualquier nombre de usuario que prefiera:

      Se le harán algunas preguntas, comenzando con la contraseña de la cuenta.

      Introduzca una contraseña segura y, opcionalmente, complete la información adicional si lo desea. Esto no es obligatorio y puede pulsar ENTER en cualquier campo que desee omitir.

      Paso 3: Conceder privilegios administrativos

      Ahora, tenemos una nueva cuenta de usuario con privilegios de una cuenta regular. Sin embargo, a veces necesitaremos realizar tareas administrativas.

      Para evitar tener que cerrar la sesión de nuestro usuario normal y volver a iniciar sesión como cuenta root, podemos configurar lo que se conoce como “superusuario” o privilegios root para nuestra cuenta normal. Esto permitirá a nuestro usuario normal ejecutar comandos con privilegios administrativos anteponiendo la palabra sudo a cada comando.

      Para añadir estos privilegios a nuestro nuevo usuario, debemos agregarlo al grupo sudo. Por defecto, en Ubuntu 20.04, los usuarios que son miembros del grupo sudo pueden usar el comando sudo.

      Como root, ejecute este comando para añadir su nuevo usuario al grupo sudo (sustituya el nombre de usuario resaltado por su nuevo usuario):

      Ahora, cuando inicie sesión como usuario normal, puede escribir sudo antes de los comandos para realizar acciones con privilegios de superusuario.

      Paso 4: Configurar un firewall básico

      Los servidores Ubuntu 20.04 pueden usar el firewall UFW para garantizar que solo se permiten las conexiones con ciertos servicios. Podemos configurar un firewall básico fácilmente usando esta aplicación.

      Nota: Si sus servidores están funcionan con DigitalOcean, puede usar de manera opcional los firewalls en la nube de DigitalOcean en lugar del firewall UFW. Recomendamos usar solo un firewall a la vez para evitar reglas conflictivas que pueden ser difíciles de depurar.

      Las aplicaciones pueden registrar sus perfiles con UFW tras la instalación. Estos perfiles permiten a UFW gestionar estas aplicaciones por su nombre. OpenSSH, el servicio que nos permite conectar con nuestro servidor ahora, tiene un perfil registrado con UFW.

      Puede ver esto escribiendo lo siguiente:

      Output

      Available applications: OpenSSH

      Debemos asegurarnos que el firewall permite conexiones SSH de forma que podamos iniciar sesión de nuevo la próxima vez. Podemos permitir estas conexiones escribiendo lo siguiente:

      Posteriormente, podemos habilitar el firewall escribiendo:

      Escriba y y pulse INTRO para continuar. Puede ver que las conexiones SSH aún están permitidas escribiendo lo siguiente:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      Ya que el firewall está bloqueando actualmente todas las conexiones excepto SSH, si instala y configura servicios adicionales, deberá ajustar la configuración del firewall para permitir el tráfico entrante. Puede obtener más información sobre algunas operaciones comunes de UFW en nuestra guía Puntos esenciales de UFW.

      Paso 5: Habilitar el acceso externo para su usuario normal

      Ahora que tenemos un usuario regular para el uso cotidiano, debemos asegurarnos que podemos realizar SSH en la cuenta directamente.

      Nota: Mientras no verifique que pueda iniciar sesión y usar sudo con su nuevo usuario, le recomendamos permanecer conectado como root. De esta manera, si tiene problemas, puede resolverlos y realizar cualquier cambio necesario como root. Si utiliza un Droplet de DigitalOcean y experimenta problemas con su conexión SSH de root, puede iniciar sesión en el Droplet usando la consola de DigitalOcean.

      El proceso para configurar el acceso SSH de su nuevo usuario depende de que en la cuenta root de su servidor se utilicen una contraseña o claves SSH para la autenticación.

      Si en la cuenta root se utiliza la autenticación con contraseña

      Si inició sesión en su cuenta root usando una contraseña, entonces la autenticación con contraseña estará habilitada para SSH. Puede aplicar SSH en su nueva cuenta de usuario abriendo una nueva sesión de terminal y usando SSH con su nuevo nombre de usuario:

      Después de ingresar la contraseña de su usuario normal, iniciará sesión. Recuerde que si necesita ejecutar un comando con privilegios administrativos debe escribir sudo antes de este, como se muestra a continuación:

      Se le solicitará la contraseña de su usuario normal cuando utilice sudo por primera vez en cada sesión (y periódicamente después).

      Para mejorar la seguridad de su servidor, le recomendamos enfáticamente establecer claves de SSH en lugar de usar la autenticación con contraseña. Siga nuestra guía de configuración de claves de SSH en Ubuntu 20.04 para aprender a configurar la autenticación basada en claves.

      Si en la cuenta root se utiliza la autenticación con clave SSH

      Si inició sesión en su cuenta root usando claves SSH, la autenticación con contraseña estará desactivada para SSH. Para iniciar sesión correctamente deberá añadir una copia de su clave pública local al archivo ~/.ssh/authorized_keys del nuevo usuario.

      Debido a que su clave pública ya está en el archivo ~/.ssh/authorized_keys de la cuenta root, podemos copiar esa estructura de archivos y directorios a nuestra nueva cuenta de usuario en nuestra sesión existente.

      El medio más sencillo para copiar los archivos con la propiedad y los permisos adecuados es el comando rsync. Con este, se copiará el directorio .ssh del usuario root, se conservarán los permisos y se modificarán los propietarios de archivos; todo a través de un solo comando. Asegúrese de cambiar las porciones resaltadas del comando que se muestra a continuación para que coincida con el nombre de su usuario normal:

      Nota: El comando rsync trata de manera diferente las fuentes y destinos que tienen una barra diagonal al final respecto de aquellos que no la tienen. Al usar rsync a continuación, asegúrese de que en el directorio de origen (~/.ssh) no se incluya una barra diagonal al final (verifique que no esté usando ~/.ssh/).

      Si accidentalmente añade una barra diagonal al final del comando, en rsync se copiará el contenido del directorio ~/.ssh de la cuenta root al directorio principal del usuario sudo en lugar de la estructura de directorios completa ~/.ssh. Los archivos se encontrarán en la ubicación equivocada y SSH no podrá encontrarlos ni utilizarlos.

      • rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy

      Ahora, abra una nueva sesión terminal en su equipo local, y utilice SSH con su nuevo nombre de usuario:

      Su sesión de la nueva cuenta de usuario deberá iniciarse sin contraseña. Recuerde que si necesita ejecutar un comando con privilegios administrativos debe escribir sudo antes de este, como se muestra a continuación:

      Se le solicitará la contraseña de su usuario normal cuando utilice sudo por primera vez en cada sesión (y periódicamente después).

      ¿Dónde puedo ir desde aquí?

      En este momento, dispondrá de una base sólida para su servidor. Ahora podrá instalar el software que necesite en su servidor.



      Source link

      Automating Server Setup with Ansible: Un kit del taller de DigitalOcean


      Automatizar la configuración del servidor con materiales del kit de taller de Ansible

      Este kit de taller está diseñado para ayudar al público técnico a familiarizarse con los conceptos vinculados a la gestión de configuración y con el uso de Ansible para automatizar la configuración de la infraestructura del servidor.

      El objetivo es proporcionar un conjunto completo de recursos para que un ponente celebre un evento y de una charla introductoria sobre Ansible. Incluye lo siguiente:

      • Diapositivas y notas para el ponente; se incluyen vídeos demo cortos y comandos para ejecutar una demostración en vivo opcional. Esta charla dura aproximadamente 50 minutos.
      • Un repositorio de GitHub que contenga el código de la aplicación de demostración y las secuencias de comandos de Ansible necesarias para implementar esa aplicación en un servidor de Ubuntu.
      • Este tutorial, explica cómo implementar la demo Travellist de la aplicación Laravel en un servidor remoto.

      Este tutorial está destinado a complementar la demo de charla con detalles y aclaraciones adicionales. También sirve como referencia para los lectores que buscan implementar una aplicación de Laravel en un servidor remoto de Ubuntu usando Ansible.

      Introducción

      Debido al carácter desechable de los entornos de aplicaciones modernos, la automatización de servidores ahora desempeña un papel fundamental en la administración de sistemas. Las herramientas de gestión de configuración como Ansible normalmente se utilizan para agilizar el proceso de automatización de la configuración del servidor estableciendo procedimientos estándares para los nuevos servidores. Esto tiene el beneficio de reducir los errores humanos asociados con las configuraciones manuales.

      Ansible ofrece una arquitectura simplificada que no requiere la instalación de software especial en los nodos. También proporciona un conjunto sólido de características y módulos incorporados que facilitan la escritura de secuencias de comandos de automatización.

      Este tutorial, diseñado para acompañar a las diapositivas y las notas del ponente para el kit del taller Automatizar la configuración del servidor con Ansible, le mostrará cómo configurar un archivo de inventario y ejecutar un conjunto de secuencias de comandos de aprovisionamiento para automatizar completamente el proceso de configurar un servidor LEMP remoto (Linux, (E)Nginx, MariaDB y PHP-FPM) en Ubuntu 18.04 e implementar una aplicación demo Laravel en este sistema.

      Nota: Este material está destinado a demostrar cómo usar playbooks para automatizar la configuración del servidor con Ansible. Aunque nuestra demo consiste en una aplicación Laravel que se ejecuta en un servidor LEMP, se anima a los lectores que modifiquen y adapten la configuración incluida para que se adapte a sus propias necesidades.

      Requisitos previos

      Para este tutorial, necesitará lo siguiente:

      Paso 1: Clonar el repositorio demo

      Lo primero que debemos hacer es clonar el repositorio que contiene las secuencias de comando de aprovisionamiento de Ansible y la aplicación demo Laravel que implementaremos en los servidores remotos. Puede encontrar todos los archivos necesarios en el repositorio de Github do-community/ansible-laravel-demo.

      Tras iniciar sesión en su nodo de control de Ansible como su usuario sudo, clone el repositorio y navegue al directorio creado por el comando git:

      • git clone https://github.com/do-community/ansible-laravel-demo.git
      • cd ansible-laravel-demo

      Ahora, puede ejecutar un comando ls para inspeccionar los contenidos del repositorio clonado:

      • ls -l --group-directories-first

      Verá resultados como este:

      ansible-laravel-demo

      drwxrwxr-x 3 sammy sammy 4096 Mar 24 15:24 application
      drwxrwxr-x 2 sammy sammy 4096 Mar 24 15:24 group_vars
      drwxrwxr-x 7 sammy sammy 4096 Mar 24 15:24 roles
      -rw-rw-r-- 1 sammy sammy  102 Mar 24 15:24 inventory-example
      -rw-rw-r-- 1 sammy sammy 1987 Mar 24 15:24 laravel-deploy.yml
      -rw-rw-r-- 1 sammy sammy  794 Mar 24 15:24 laravel-env.j2
      -rw-rw-r-- 1 sammy sammy  920 Mar 24 15:24 readme.md
      -rw-rw-r-- 1 sammy sammy  318 Mar 24 15:24 server-setup.yml
      

      Aquí tiene una descripción de cada una de estas carpetas y archivos y de lo que son:

      • application/: este directorio contiene la aplicación demo Laravel que va a ser implementada en el servidor remoto al final del taller.
      • group_vars/: este directorio contiene los archivos variables que contienen opciones personalizadas para la configuración de la aplicación, como las credenciales de la base de datos y dónde guardar los archivos de la aplicación en el servidor remoto.
      • roles/: este directorio contiene los diferentes roles de Ansible que gestionan el aprovisionamiento de un servidor LEMP de Ubuntu.
      • inventory-example: este archivo puede usarse como una base para crear un inventario personalizado para su infraestructura.
      • laravel-deploy.yml: este playbook implementará la aplicación demo Laravel en el servidor remoto.
      • laravel-env.j2: el playbook laravel-deploy.yml utiliza esta plantilla para configurar el archivo de entorno de la aplicación.
      • readme.md: este archivo contiene información general sobre el aprovisionamiento contenido en este repositorio.
      • server-setup.yml: este playbook proporcionará un servidor LEMP usando los roles definidos en el diretorio roles/.

      Paso 2: Configurar el archivo de inventario y probar la conexión con los nodos

      Ahora, crearemos un archivo de inventario para listar los hosts que queremos administrar usando Ansible. Primero, copie el archivo inventory-example a un nuevo archivo llamado hosts:

      • cp inventory-example hosts

      Ahora, utilice su editor de texto favorito para abrir el nuevo archivo de inventario y actualizarlo con sus propios servidores. En este caso, utilizaremos nano:

      El inventario de ejemplo que viene con el kit de taller contiene dos grupos de Ansible: dev y production. Esto está destinado a demostrar la forma de usar variables de grupo para personalizar la implementación en varios entornos. Si desea probar esta configuración con un único nodo, puede usar dev o el grupo production y eliminar el otro del archivo de inventario.

      ansible-laravel-demo/hosts

      [dev]
      203.0.113.0.101
      
      [prod]
      203.0.113.0.102
      
      [all:vars]
      ansible_python_interpreter=/usr/bin/python3
      

      Nota: La variable ansible_python_interpreter define la ruta al ejecutable de Python en el host remoto. Aquí, indicamos a Ansible que establezca esta variable para todos los hosts en este archivo de inventario.

      Guarde y cierre el archivo cuando termine. Si utiliza nano, puede hacerlo pulsando CTRL+X, luego Y y ENTER para confirmar.

      Una vez que haya terminado de ajustar su archivo de inventario, puede ejecutar el módulo ping de Ansible para probar si el nodo de control puede conectar con los hosts:

      • ansible all -i hosts -m ping -u root

      Vamos a desglosar este comando:

      • all: esta opción indica a Ansible que ejecute el siguiente comando en todos los hosts desde el archivo de inventario designado.
      • -i hosts: especifica qué inventario debería usarse. Cuando no se proporciona esta opción, Ansible intentará usar el inventario predeterminado, que normalmente se ubica en /etc/ansible/hosts.
      • -m ping: esto ejecutará el módulo ping de Ansible, que probará la conectividad con los nodos y si el ejecutable de Python puede encontarse o no en los sistemas remotos.
      • -u root: esta opción especifica el usuario remoto que debería usarse para establecer conexión con los nodos. Estamos usando la cuenta root como ejemplo porque normalmente es la única cuenta disponibles en los servidores nuevos. Es posible que sean necesarias otras opciones de conexión dependiendo del proveedor de su infraestructura y de la configuración SSH.

      Si su conexión SSH a los nodos se configura correctamente, obtendrá el siguiente resultado:

      Output

      203.0.113.0.101 | SUCCESS => { "changed": false, "ping": "pong" } 203.0.113.0.102 | SUCCESS => { "changed": false, "ping": "pong" }

      La respuesta pong significa que su nodo de control puede establecer conexión con sus nodos gestionados y que Ansible puede ejecutar los comandos de Python en los hosts remotos.

      Paso 3: Configurar los archivos variables

      Antes de ejecutar los playbooks que están incluidos en este kit de taller, primero deberá editar el archivo de variables que contiene ajustes como el nombre del usuario remoto que se creará y las credenciales de la base de datos que se configurarán con MariaDB.

      Abra el archivo group_vars/all usando el editor de texto que prefiera:

      ansible-laravel-demo/group_vars/all.yml

      ---
      # Initial Server Setup
      remote_user: sammy
      
      # MySQL Setup
      mysql_root_password: MYSQL_ROOT_PASSWORD
      mysql_app_db: travellist
      mysql_app_user: travellist_user
      mysql_app_pass: DB_PASSWORD
      
      # Web Server Setup
      http_host: "{{ ansible_facts.eth0.ipv4.address }}"
      remote_www_root: /var/www
      app_root_dir: travellist-demo
      document_root: "{{ remote_www_root }}/{{ app_root_dir }}/public"
      
      # Laravel Env Variables
      app_name: Travellist
      app_env: dev
      app_debug: true
      app_url: "http://{{ http_host }}"
      db_host: localhost
      db_port: 3306
      db_database: "{{ mysql_app_db }}"
      db_user: "{{ mysql_app_user }}"
      db_pass: "{{ mysql_app_pass }}"
      

      Las variables que debe considerar son las siguientes:

      • remote_user: el usuario especificado se creará en el servidor remoto y se le concendrán privilegios sudo.
      • mysql_root_password: esta variable define la contraseña root de la base de datos para el servidor de MariaDB. Observe que esta debería ser una contraseña segura que usted elija.
      • mysql_app_db: el nombre de la base de datos que va a crear para la aplicación Laravel. No es necesario que cambie este valor, pero puede hacerlo si lo desea. Este valor se usará para establecer el archivo de configuración .env de Laravel.
      • mysql_app_user: el nombre del usuario de la base de datos para la aplicación Laravel. De nuevo, no es necesario que cambie este valor, pero puede hacerlo si lo desea.
      • mysql_app_pass: la contraseña de la base de datos para la aplicación Laravel. Esta debería ser una contraseña segura de su elección.
      • http_host: el nombre de dominio o dirección IP del host remoto. Aquí, recurriremos al hecho de que Ansible contiene la dirección ipv4 para la interfaz de red eth0. En el caso de que tenga nombres de dominios apuntando a sus hosts remotos, es posible que desee crear archivos de variables independientes para cada uno de ellos sobrescribiendo este valor de modo que la configuración de Nginx contenga el hostname correcto para cada servidor.

      Una vez que termine de editar estos valores, guarde y cierre el archivo.

      Crear archivos de variables adicionales para varios entornos

      Si configuró su archivo de inventario con varios nodos, es posible que desee crear archivos de variables adicionales para configurar cada nodo de forma adecuada. En nuestro inventario de ejemplo, creamos dos grupos distintos: dev y production. Para evitar tener las mismas credenciales de la base de datos y otros ajustes en ambos entornos, debemos crear un archivo variable independiente que albergue nuestros valores de producción.

      Es posible que desee copiar el archivo variable y usarlo como base para sus valores de producción:

      • cp group_vars/all.yml group_vars/production.yml
      • nano group_vars/production.yml

      Debido a que el archivo all.yml contiene los valores predeterminados que deberían ser válidos para todos los entornos, puede eliminar del nuevo archivo production.yml todas las variables que no necesitarán modificaciones. Las variables que debería actualizar para cada entorno se resaltan aquí:

      ansible-laravel-demo/group_vars/production

      ---
      # Initial Server Setup
      remote_user: prod_user
      
      # MySQL Setup
      mysql_root_password: MYSQL_PROD_ROOT_PASSWORD
      mysql_app_pass: MYSQL_PROD_APP_PASSWORD
      
      # Laravel Env Variables
      app_env: prod
      app_debug: false
      

      Observe que cambiamos el valor de app_env a prod y fijamos el valor app_debug en false. Estos son los ajustes de Laravel recomendados para los entornos de producción.

      Cuando termine de personalizar sus variables de producción, guarde y cierre el archivo.

      Cifrar archivos variables con Ansible Vault

      Si planea compartir su configuración Ansible con otros usuarios, es importante mantener las credenciales y otros datos sensibles de sus archivos variables protegidos. Esto es posible con Ansible Vault, una función que se incluye con Ansible por defecto. Ansible Vault le permite cifrar archivos de variables de modo que solo los usuarios con acceso a la contraseña de almacén puedan ver, editar o descifrar estos archivos. La contraseña de almacén es también necesaria para ejecutar un playbook o un comando que utilice archivos cifrados.

      Para cifrar su archivo de variables de producción, ejecute lo siguiente:

      • ansible-vault encrypt group_vars/production.yml

      Se le solicitará proporcionar una contraseña de almacén y confirmarla. Una vez que termine, si comprueba el contenido del archivo, verá que los datos estarán cifrados.

      Si desea ver el archivo variable sin cambiar su contenido, puede usar el comando view.

      • ansible-vault view group_vars/production.yml

      Se le pedirá que proporcione la misma contraseña que definió cuando cifró ese archivo con asnible-vault. Tras proporcionar la contraseña, el contenido del archivo aparecerá en su terminal. Para salir de la vista de archivo, escriba q.

      Para editar un archivo previamente cifrado con Ansible Vault, utilice el comando de almacén edit:

      • ansible-vault edit group_vars/production.yml

      Este comando lo solicitará proporcionar la contraseña de almacén para el archivo. Su editor de terminal predeterminado se utilizará para abrir el archivo para su edición. Tras realizar los cambios deseados, guarde y cierre el archivo. Ansible Vault lo cifrará de nuevo automáticamente.

      Ahora ha terminado de configurar sus archivos variables. En el siguiente paso, ejecutaremos el playbook para configurar Nginx, PHP-FPM y MariaDB (que junto con un sistema operativo basado en Linux como Ubuntu forman la pila LEMP) en sus servidores remotos.

      Paso 4: Ejecutar el playbook de LEMP

      Antes de implementar la aplicación demo Laravel en los servidores remotos, debemos configurar un entorno LEMP que presentará la aplicación. El playbook server-setup.yml incluye los roles de Ansible necesarios para configurar esto. Para inspeccionar sus contenidos, ejecute:

      ansible-laravel-demo/server-setup.yml

      ---
      - hosts: all
        become: true
        roles:
          - { role: setup, tags: ['setup'] }
      
          - { role: mariadb, tags: ['mysql', 'mariadb', 'db', 'lemp'] }
      
          - { role: php, tags: ['php', 'web', 'php-fpm', 'lemp'] }
      
          - { role: nginx, tags: ['nginx', 'web', 'http', 'lemp'] }
      
          - { role: composer, tags: ['composer'] }
      

      Aquí tiene una descripción de los roles incluidos en este playbook:

      • setup: contiene las tareas necesarias para crear un nuevo usuario del sistema y concederle privilegios sudo, y para habilitar el firewall ufw.
      • mariadb: instala la el servidor de la base de datos MariaDB y crea la base de datos y el usuario de la aplicación.
      • php: instala php-fpm y los módulos PHP que son necesarios para ejecutar una aplicación Laravel.
      • nginx: instala el servidor web Nginx y permite el acceso en el puerto 80.
      • composer: instala Composer globalmente.

      Observe que hemos configurado algunas etiquetas en cada rol. Esto es para que resulte sencillo volver ejecutar solo partes de este playbook, si es necesario. Si realiza cambios en su archivo de plantilla de Nginx, por ejemplo, es posible que desee ejecutar solo el rol de Nginx.

      El siguiente comando ejecutará este playbook en todos los servidores desde su archivo de inventario. El --ask-vault-pass solo es necesario en caso de que haya usado ansible-vault para cifrar archivos variables en el paso anterior:

      • ansible-playbook -i hosts server-setup.yml -u root --ask-vault-pass

      Verá un resultado similar a este:

      Output

      PLAY [all] ********************************************************************************************** TASK [Gathering Facts] ********************************************************************************** ok: [203.0.113.0.101] ok: [203.0.113.0.102] TASK [setup : Install Prerequisites] ******************************************************************** changed: [203.0.113.0.101] changed: [203.0.113.0.102] ... RUNNING HANDLER [nginx : Reload Nginx] ****************************************************************** changed: [203.0.113.0.101] changed: [203.0.113.0.102] PLAY RECAP ********************************************************************************************** 203.0.113.0.101 : ok=31 changed=27 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1 203.0.113.0.102 : ok=31 changed=27 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1

      Sus nodos ahora están listos para presentar aplicaciones PHP usando Nginx+PHP-FPM, con MariaDB como el servidor de la base de datos. En el siguiente paso, implementaremos la aplicación demo Laravel incluida con el playbook de Ansible laravel-deploy.yml.

      Paso 5: Implementar la aplicación de Laravel

      Ahora que tiene un entorno LEMP en funcionamiento en su servidor remoto, puede ejecutar el playbook laravel-deploy.yml. Este playbook ejecutará las siguientes tareas:

      1. Crear la raíz del documento de la aplicación en el servidor remoto, si esto aún no se hizo.
      2. Sincronizar la carpeta de la aplicación local con el servidor remoto usando el módulo sync.
      3. Usar el módulo acl para establecer permisos para el usuario www-data en la carpeta de almacenamiento.
      4. Configurar el archivo de aplicación .env en base a la plantilla laravel-env.j2.
      5. Instalar las dependencias de la aplicación con Composer.
      6. Generar la clave de seguridad de la aplicación.
      7. Configurar un enlace público para la carpeta de almacenamiento.
      8. Ejecutar migraciones y seeders de la base de datos.

      Este playbook debería ejecutarse a través de un usuario no root con permisos sudo. Este usuario se creó cuando ejecutó el playbook server-setup.yml en el paso anterior, usando el nombre definido por la variable remote_user.

      Cuano esté listo, ejecute el playbook laravel-deploy.yml con:

      • ansible-playbook -i hosts laravel-deploy.yml -u sammy --ask-vault-pass

      El --ask-vault-pass solo es necesario en caso de que haya usado ansible-vault para cifrar archivos variables en el paso anterior.

      Verá un resultado similar a este:

      Output

      PLAY [all] ********************************************************************************************** TASK [Gathering Facts] ********************************************************************************** ok: [203.0.113.0.101] ok: [203.0.113.0.102] TASK [Make sure the remote app root exists and has the right permissions] ******************************* ok: [203.0.113.0.101] ok: [203.0.113.0.102] TASK [Rsync application files to the remote server] ***************************************************** ok: [203.0.113.0.101] ok: [203.0.113.0.102] ... TASK [Run Migrations + Seeders] ************************************************************************* ok: [203.0.113.0.101] ok: [203.0.113.0.102] PLAY RECAP ********************************************************************************************** 203.0.113.0.101 : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 203.0.113.0.102 : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

      Cuando finalice la ejecución, podrá acceder a la aplicación demo apuntando su navegador al nombre de dominio o dirección IP de su nodo:

      http://node_domain_or_IP
      

      Verá una página como la siguiente:

      Demo Travellist de Laravel

      Conclusión

      En este tutorial, se muestra la manera de configurar un archivo de inventario de Ansible, establecer conexión con nodos remotos y ejecutar playbooks de Ansible para configurar un servidor LEMP e implementar una aplicación de demostración de Laravel en él. Esta guía complementa las diapositivas y notas del ponente de Automatizar la configuración del servidor con el Kit del taller Ansible; además, viene acompañada de un repositorio de GitHub de demostración que contiene todos los archivos necesarios para seguir con el componente de demostración de este taller.



      Source link