Mateo Martínez, Author at Software Evolutivo

Esenciales para la Administración de Servidores Linux

Mateo Martínez — Sun, 30 Jun 2024 23:27:24 +0000

Los servidores son la columna vertebral de las redes informáticas, proporcionando servicios esenciales a otros dispositivos o clientes en la red. En el ámbito de los servidores, Linux se ha consolidado como una opción muy popular y robusta debido a su estabilidad, seguridad y flexibilidad. Estos servidores pueden manejar una amplia variedad de tareas, desde alojar sitios web y gestionar bases de datos hasta operar aplicaciones empresariales y servicios de correo electrónico.

Contenido:

Sistemas Operativos

Los sistemas operativos tipo Unix son conocidos por su robustez y amplia utilización en servidores y estaciones de trabajo. A continuación, se presentan algunos ejemplos destacados:

Linux es un sistema operativo de tipo Unix-like con una arquitectura y filosofía común basada en la idea de que “todo es un archivo”. Multiusuario y multitarea, permite la ejecución simultánea de múltiples tareas por diferentes usuarios.

Distribuciones de Linux:

Rolling Release: Ejemplos como Arch Linux y Manjaro. Estas distribuciones reciben actualizaciones continuas, lo que proporciona las últimas características y mejoras de software de manera constante.
Fixed Release: Ejemplos como Debian, Ubuntu y Fedora. Estas distribuciones lanzan versiones específicas con actualizaciones periódicas no solo de seguridad, sino también funcionales. Están diseñadas para diferentes públicos objetivos, como hackers, servidores, usuarios comunes, gamers, entre otros. Algunas distribuciones son más estables que otras, y cada una está optimizada para cierto tipo de trabajo.

Sistemas de archivos en Linux

Los sistemas de archivos son métodos estructurados para almacenar y organizar datos en dispositivos de almacenamiento, como discos duros y unidades flash. Cada sistema de archivos tiene características distintas que afectan su rendimiento, confiabilidad y capacidad de manejar diferentes tipos de datos.

A continuación, se presentan algunos sistemas de archivos en entornos Linux:

Btrfs: Diseñado para manejar grandes conjuntos de datos con alta redundancia y escalabilidad.
Ext4: Predeterminado en muchas distribuciones, conocido por su rendimiento y confiabilidad.
XFS: Adecuado para sistemas de archivos muy grandes.
NTFS, FAT32: Compatibles con Windows, utilizados comúnmente en unidades portátiles.

El Rol del Administrador de Servidores

Habilidades clave:

Control de accesos: Gestión de permisos y autenticación de usuarios.
Monitoreo del sistema: Uso de herramientas como top, htop, y ps para supervisar procesos y recursos.
Administración de recursos: Gestión eficiente de CPU, memoria, y almacenamiento.
Troubleshooting: Resolución de problemas mediante logs y herramientas de diagnóstico.
Instalación y mantenimiento de software: Uso de manejadores de paquetes como APT y DNF (antes YUM).
Creación de respaldos: Planificación y ejecución de respaldos regulares.
Documentación: Mantener registros detallados de configuraciones y cambios.

Roles específicos:

DevOps Engineer: Enfocado en la integración y entrega continua en el desarrollo de software.
Site Reliability Engineer: Garantiza la operación y confiabilidad de los sistemas.
Security Operations Engineer: Encargado de la seguridad a nivel de red y aplicaciones.
Network Engineer, Database Administrator, Cloud Engineer, etc.

Instalación de Servidores

Métodos de instalación:

Instalación directa: Descargar una imagen ISO y utilizarla para instalar el sistema operativo en el hardware.
Virtualización: Uso de software como VirtualBox o KVM para crear máquinas virtuales.
Hypervisor Tipo 1: Ejemplo: VMware ESXi, KVM, instalados directamente en el hardware.
Hypervisor Tipo 2: Ejemplo: VirtualBox, está instalado sobre un sistema operativo host.

Gestión de Usuarios y Permisos

Creación de usuarios:
useradd nombre_usuario
Asignación de contraseñas: passwd nombre_usuario
passwd nombre_usuario
Gestión de grupos:
groupadd nombre_grupo
usermod -aG nombre_grupo nombre_usuario

Administración de memoria y almacenamiento

Visualización de dispositivos de almacenamiento:
lsblk
Gestión de particiones:
fdisk /dev/sdX
parted /dev/sdX
Formateo de particiones, con los diferentes sistemas de archivos:
mkfs.ext4 /dev/sdX1
mkfs.xfs /dev/sdX1
mkfs.btrfs /dev/sdX1
mkfs.ntfs /dev/sdX1
mkfs.fat -F 32 /dev/sdX1
Montaje y desmontaje de sistemas de archivos:
mount /dev/sdX1 /mnt
umount /mnt
Visualización del espacio de almacenamiento:
df -h
du -sh /ruta
Gestión de volúmenes lógicos con LVM:
LVM (Logical Volume Manager) es una tecnología de administración de almacenamiento que permite gestionar volúmenes lógicos en Linux de manera flexible y dinámica. Con LVM, puedes crear, modificar y eliminar volúmenes lógicos sin necesidad de apagar el sistema ni mover datos.
Este es un tema muy amplio. Más adelante, profundizaremos sobre LVM en un blog dedicado, donde exploraremos cada comando y su aplicación práctica en escenarios de administración de almacenamiento en Linux.

Monitoreo y Mantenimiento del Sistema

Monitoreo de procesos y recursos:
Comando ps: Lista procesos en ejecución.
ps aux
Comando top: Monitorean el uso de recursos en tiempo real.
top
Comando lsof: Lista archivos abiertos y los procesos que los utilizan.
lsof -i :80 (ver procesos que usan el puerto 80)
Buscar ID de un proceso:
pidof nombre_proceso
El comando kill -15 PID se usa para enviar una señal de terminación al proceso especificado por su PID.
Se puede reemplazar el -15 por el número -9 que corresponde a la señal SIGKILL, que fuerza la terminación inmediata del proceso sin permitir que el proceso realice ninguna limpieza o cierre ordenado de recursos.

Gestión de demonios y servicios:
Uso de systemd:
Crear y gestionar demonios
systemctl start nombre_servicio
systemctl enable nombre_servicio
Para crear un nuevo servicio personalizado en systemd, debes crear un archivo de unidad en el directorio /etc/systemd/system/.
EjemploTe dejamos un ejemplo de un archivo de unidad para el servicio D-Bus (sistema de mensajería que permite que diferentes aplicaciones se comuniquen entre sí). Este archivo configura cómo se debe iniciar, detener y recargar el servicio D-Bus en el sistema, con sus dependencias y configuraciones de entorno.

Seguridad

Asegurar la seguridad en sistemas Linux implica implementar prácticas y herramientas adecuadas para proteger el sistema contra accesos no autorizados y vulnerabilidades. Aquí se presentan algunas medidas básicas y cómo utilizar herramientas específicas para configurar firewalls y gestionar actualizaciones:

Configuración de firewalls:
Uso de ufw (Ubuntu):
ufw allow 22/tcp
ufw enable
Uso de firewalld (CentOS, Fedora, Red Hat, Oracle Linux):
firewall-cmd --permanent --add-service=http
firewall-cmd --reload

Gestión de actualizaciones y parches:
apt update && apt upgrade (Debian/Ubuntu)
dnf update (Red Hat/CentOS)
Configuración de SSH: Asegurar el acceso remoto.
Cambios en el SSH: Editar /etc/ssh/sshd_config, se recomienda realizar los siguientes cambios:
Cambio del puerto SSH
Desactivar el acceso como root
Restringir usuarios específicos
Configurar autenticación de clave pública
Limitar protocolos y cifrados débiles
Configuración de timeout y límites de intentos

Automatización con cron jobs

Configurar y utilizar cron jobs de manera efectiva ayuda a automatizar procesos rutinarios y a mantener la consistencia y eficiencia del sistema operativo Linux. Es importante verificar regularmente los cron jobs existentes y asegurarse de que funcionen según lo esperado para evitar problemas y mantener la integridad del sistema.

Validación del estado del demonio de cron:
systemctl status cron
Creación de cron jobs:
Editar crontab:
crontab -e
Sintaxis de crontab: minuto hora día_mes mes día_semana comando
Ejemplo (Ejecutar backup.sh todos los días a las 2 AM):
0 2 * * * /path/to/backup.sh
Listar cron jobs:
crontab -l

Respaldo y Recuperación

Métodos de creación de respaldos:
Respaldo con tar:
tar -czf /ruta/destino/respaldo.tar.gz /ruta/origen
Respaldo incremental con rsync:
rsync -av --delete /ruta/origen /ruta/destino
Uso de herramientas de respaldo:
duplicity
borg
Estrategias de recuperación:
Restauración de archivos con tar:
tar -xzf respaldo.tar.gz -C /ruta/destino
Restauración de archivos con rsync:
rsync -av /ruta/destino/ /ruta/origen
Planificación de recuperación ante desastres:
Documentar procedimientos de recuperación.
Realizar pruebas regulares de restauración.

Administración de Paquetes

Manejadores de paquetes:
APT (Debian/Ubuntu):
Actualizar lista de paquetes: sudo apt update
Instalar un paquete: sudo apt install nombre_paquete
Eliminar un paquete: sudo apt remove nombre_paquete
YUM (Red Hat/CentOS):
Actualizar lista de paquetes: sudo yum update
Instalar un paquete: sudo yum install nombre_paquete
Eliminar un paquete: sudo yum remove nombre_paquete
DNF (Fedora/CentOS 8+):
Actualizar lista de paquetes: sudo dnf update
Instalar un paquete: sudo dnf install nombre_paquete
Eliminar un paquete: sudo dnf remove nombre_paquete

En conclusión, la administración de servidores Linux contempla una amplia gama de competencias y conocimientos, desde la instalación y configuración inicial hasta el monitoreo, mantenimiento y seguridad continuos.

Conoce nuestros servicios

Orquestación de Aplicaciones y Servicios

Nuestro enfoque en Kubernetes está diseñado para impulsar la escalabilidad de su infraestructura de TI.

The post Esenciales para la Administración de Servidores Linux appeared first on Software Evolutivo.

DevOps: CI/CD en proyectos de desarrollo ágil

Mateo Martínez — Tue, 05 Mar 2024 13:42:28 +0000

En el desarrollo ágil de proyectos de software, la calidad del resultado, la velocidad de entrega del producto y la tolerancia a fallos son aspectos fundamentales para el éxito de los mismos. En este contexto, DevOps (Development – Operations) ha surgido como un enfoque integral que busca mejorar la colaboración entre los equipos de desarrollo y de operaciones. Su principal objetivo es permitir entregas ágiles de software sin perder la estabilidad de las operaciones de la organización.

Al implementar DevOps, se busca cumplir con los principios establecidos en el Manifiesto Ágil. Particularmente, el principio que enfatiza la entrega temprana y continua de software con valor para satisfacer al cliente se alinea perfectamente con la filosofía de DevOps de ofrecer cambios de manera rápida y confiable.

Dentro de DevOps, surge un término importante “pipelines” que se define como una serie de pasos automatizados que permiten la integración continua de software (CI) y la entrega o despliegue continuo del mismo (CD). Esto asegura que el código se incorpore, pruebe y despliegue de forma ininterrumpida, facilitando a los equipos de desarrollo la entrega ágil y fiable de cambios.

DevOps no se trata simplemente de adoptar nuevas herramientas tecnológicas y acelerar procesos, sino de un cambio cultural en el cual se busca promover la comunicación, la colaboración entre los equipos. Los procesos de DevOps no son estáticos, sino más bien orgánicos y evolutivos. Cada equipo de desarrollo tiene sus propias necesidades y desafíos únicos, por lo que no existe una receta mágica o un enfoque único que funcione para todos.

El resultado de aplicar DevOps en una organización será una mayor agilidad, resiliencia y capacidad de innovación.

Integración Continua (CI)

Este proceso tiene su origen con la metodología ágil Extreme Programming, la cual busca la entrega de software de alta calidad de manera rápida y continua. CI busca integrar el trabajo de cada uno de los desarrolladores constantemente. Cada integración debe estar respaldada por pruebas automatizadas que permitirán detectar errores para corregirlos lo antes posible.

El objetivo principal de CI es reducir el riesgo de errores y conflictos de integración que dificulten el progreso de un proyecto. Una de las razones para adoptar Integración Continua (CI) es evitar el temido “Big Bang Integration”, es decir, a la práctica de integrar grandes volúmenes de código de diferentes desarrolladores o equipos al final del ciclo de desarrollo, en lugar de integrarlo de manera continua a lo largo del proceso.

Trunk Based Development (TBD) es una estrategia de desarrollo de software que fomenta la integración continua al reducir la complejidad de fusionar cambios y alentar a los equipos a integrar su trabajo con frecuencia en la rama principal, por lo que el CI está estrechamente relacionado a TBD.

Entrega Continua (CD)

Cuando el código pasó por el CI, todos los miembros del equipo de desarrollo tendrán disponible los últimos cambios del código, lo cual es muy útil. Pero el desarrollo de software tiene que seguir su ciclo de vida, y precisamente esa es la ayuda que nos va a dar esta primera variante del CD, que se define como una serie de pasos automatizados a seguirse para el que el código se encuentre en un estado listo para desplegar, es decir, todos sus artefactos (.jar, .war, imágen de contenedor) listos para que alguien tome la decisión y los despliegue en un servidor.

Despliegue Continuo (CD)

Esta segunda variante de CD es el complemento de la primera, con la gran diferencia que en este caso, no solo se busca dejar los artefactos listos para que alguien los despliegue, sino que el despliegue en el servidor es automático.

Para lograr esto, es fundamental contar con las herramientas y/o infraestructura adecuadas que permitan realizar cambios sin afectar los servicios en producción, lo que se conoce como despliegue sin tiempo de inactividad (Zero-Downtime Deployment).

La idea detrás del Zero-Downtime Deployment es asegurar que los usuarios finales puedan continuar utilizando la aplicación sin experimentar ningún tiempo de inactividad, esto se logra mediante la implementación de estrategias y técnicas específicas que permiten desplegar las nuevas versiones de la aplicación, entre las estrategias más comunes se encuentran:

– Blue-green deployment: Despliega dos entornos de producción, donde uno está activo y otro se actualiza. Una vez probada la nueva versión, el tráfico se redirige al nuevo entorno.
– Canary deployment: Implementa una nueva versión inicialmente para un pequeño grupo de usuarios o servidores, permitiendo probarla antes de implementarla completamente.
– Rolling deployment: Despliega nuevas versiones de la aplicación en etapas o secuencialmente en diferentes partes de la infraestructura, manteniendo la aplicación en línea durante todo el proceso.

Volviendo a CI y CD, contamos con varias herramientas en el mercado que nos pueden ayudar a correr pipelines en nuestros proyectos: Jenkins, GitLab, Travis CI, CircleCI, Spinnaker, AWS CodeDeploy, Azure DevOps, entre otras.

Particularmente “GitLab” es una herramienta que para la empresa Software Evolutivo es una de las mejores no solo para DevOps, sino también para la gestión y planificación de proyectos de software. Seguramente, pronto estaremos profundizando sobre esta herramienta en otro blog que te dejaremos en las lecturas recomendadas.

¿Cómo diseñar un pipeline de CI/CD para un proyecto?

– Identifica el flujo de trabajo y el ciclo de vida completo de tu proyecto desde el momento cero hasta el momento en que este sale a un ambiente de producción o cualquiera que sea el ambiente objetivo.
– Determina los pasos que tu pipeline debería seguir para que el ciclo de vida que identificaste pueda ser automatizado.

En este punto deberías tenerlo todo sentado en papel, sigamos:

– Considera el estado y las características tecnológicas de tu proyecto.
– Investiga las herramientas que te permitirán implementar tu pipeline (valida que los recursos tecnológicos y económicos requeridos estén a tu alcance).
– Define las herramientas a utilizar.

Es momento de desarrollar, y para esto se sugiere lo siguiente:

– Incluye un paso a la vez a tu pipeline, pruébalo y valida que cada paso logre su objetivo.
– Empieza por implementar el CI desde lo más simple y fundamental para que puedas continuar (compilación, tests).
– Continúa por un CD de delivery. Lograr que tu aplicación genere y suba su artefacto en el repositorio que deseas, será un gran hito.
– Cuando tengas el artefacto en el repositorio deberás buscar la manera adecuada de que tu repositorio se conecte a tu servidor donde harás el despliegue.

Y por último, busca siempre la retroalimentación de tu equipo con el objetivo de mejora continua.

Desafíos al implementar DevOps

– Superar la resistencia a los cambios y fomentar una cultura de colaboración y responsabilidad compartida.
– Lograr la automatización completa de los procesos de desarrollo, pruebas y despliegue.
– Comunicar efectivamente los beneficios de DevOps y proporcionar capacitación y apoyo para la transición.
– Integrar prácticas de seguridad y cumplimiento sin comprometer la velocidad de entrega.
– Establecer una estrategia de monitoreo y retroalimentación continua para mejorar el rendimiento y la calidad del software.
– Diseñar una infraestructura y procesos que puedan crecer y adaptarse a medida que los proyectos y equipos evolucionan.

En conclusión, DevOps y CI/CD son dos conceptos sumamente relacionados que se basan en los principios de colaboración, automatización y entrega continua para impulsar la excelencia en el desarrollo y entrega de software en entornos ágiles.

Conoce nuestros servicios

Cultura DevOps

Impulsa la colaboración, agilidad y excelencia

Transforme su equipo en un motor de entrega continua y logre resultados sorprendentes.

Conoce más

The post DevOps: CI/CD en proyectos de desarrollo ágil appeared first on Software Evolutivo.

Scrum: El rol del Product Owner

Mateo Martínez — Thu, 15 Dec 2022 21:55:04 +0000

El marco de trabajo “Scrum” dentro del desarrollo de software, sugiere un conjunto de buenas prácticas aplicadas al desarrollo de productos de software, estas permiten mejorar el trabajo en equipo y busca obtener los mejores resultados. Para lograr su objetivo, Scrum sugiere que cada equipo cuente con 3 roles principales: el Product Owner, el Scrum Master y el Equipo de Desarrollo.

Es muy común confundir las tareas y objetivos que cada rol cumple sobre todo con el Product Owner, quien ocupa un lugar menos técnico en el equipo, por lo tanto, el objetivo de este blog será dejar en claro cuáles son las responsabilidades, retos y características que un Product Owner tiene.

Figura 1. El Product Owner y sus responsabilidades.

El objetivo principal del Product Owner (PO) es optimizar el valor del producto final entregado por todo el equipo de desarrollo hacia el cliente.

Para poder cumplir con este objetivo el PO es responsable de:

– Desarrollar y comunicar de manera clara a todo el equipo sobre los objetivos del producto, para saber hacia dónde se encamina el trabajo a realizarse.
– Comunicar explícitamente sobre los elementos de trabajo, es decir, entrar en detalles sobre las especificaciones de lo que se va a desarrollar a través de cada entregable (conocido también como sprint).
– Mantener una comunicación con el Scrum Master y el Equipo de Desarrollo siempre transparente y comprensiva, además, se sugiere que sea hablada y no escrita para facilitar el feedback (retroalimentación) y la resolución de dudas.

Retos a los que el Product Owner se enfrenta

En cuanto a la cultura ágil se refiere, el PO deberá mantener la orientación a las entregas, las prácticas que se adaptan al equipo en base a la experiencias y evidencias del equipo.

En cuanto a la cultura empresarial, el PO se enfrenta a desafíos relacionados a los resultados del producto, principios y prácticas, y a la retroalimentación en cada entrega del producto.

Enfrentarse a estos retos no es algo sencillo, para que un miembro del equipo califique para desempeñarse como Product Owner deberá:

– Tener conocimiento del negocio.
– Tener conocimiento del producto para identificar los puntos fuertes y débiles de este para mejorarlos y tener un dominio sobre todas las aristas.
– Tener conocimiento del contexto en el que se encuentra el usuario final.
– Desarrollar un correcto análisis del negocio, es decir, entender los problemas y estar en la capacidad de ofrecer soluciones en base al cliente, el equipo y la organización.

Además, las habilidades blandas que se identifican en un PO son:

– Influencia positiva en el equipo.
– Comunicación y buen diálogo durante las reuniones. Permite siempre llegar a soluciones y conclusiones productivas.
– Negociación constante tanto con el cliente como con el equipo.
– Abstracción y categorización de toda la cantidad de información que recibe para poder comunicar y llegar con el mensaje al resto del equipo.

El trabajo del Product Owner

Hemos revisado las características de un Product Owner de una manera un tanto general, ahora en la práctica, en el día a día quien ocupe este rol deberá realizar actividades como las siguientes:

– Determinar los objetivos de un producto.
– Definir y crear el backlog mediante las características del producto.
– Gestionar y priorizar el backlog creado.
– Crear las historias de usuario. (Para más info “Mejores Historias de Usuario para Scrum”)
– Para garantizar el desarrollo adecuado del producto debe estar presente en:
– Reuniones de refinamiento de los pendientes (semanales).
– Reuniones para revisar los sprints.

Interacción con el resto del equipo

Figura 2. Interacción del Product Owner.

Al ser el Product Owner la voz del cliente y el negociador principal entre él y el equipo de desarrollo, el PO interactúa constantemente con el resto del equipo en situaciones como:

– Para el desarrollo del backlog, se tiene en cuenta la opinión y perspectiva de todo el equipo.
– En la planeación del sprint, se realiza la estimación en base a un consenso entre todos quienes colaboran en el proyecto.
– Cuando surgen impedimentos o bloqueos para el avance del proyecto, el PO tiene la responsabilidad de interactuar con el equipo para informar y establecer qué tan prioritaria es la entrega del elemento que está teniendo el bloqueo en cuestión o cuánto valor puede entregar al cliente este elemento.
– En la revisión del sprint, el PO tiene que reunir al equipo y a los involucrados relevantes para que se realice una inspección de lo que se está entregando.
– El PO participa en la retrospectiva del sprint y durante ese período debe tratar de participar en todas las dailys.

Importante

Establezcamos un par de roles con los que más a menudo solemos confundir al Product Owner:

– El Business Analyst identifica y define soluciones para maximizar el valor que se entrega en un proyecto, se lo confunde con el PO pero en la práctica el PO suele tener un Business Analyst para ayudarlo en la toma de decisiones, sin embargo la diferencia radica en que solo el PO puede priorizar en base a la información de la que dispone.
– El Product Manager es quien crea las estrategias del producto pero a un nivel más global, en este caso es el Product Manager quien puede tener a varios Product Owner trabajando en diferentes partes de un proyecto.

Conclusiones

Al Product Owner se lo puede definir de manera sencilla como ”la voz del usuario final en el equipo de desarrollo”, cumple con un rol estándar dentro del marco de Scrum y su trabajo se enfoca principalmente en realizar la entrega de un producto de calidad que permita satisfacer tanto a cliente como a usuario final después de haber seguido un largo pero claro y organizado camino junto al resto de su equipo de trabajo.

Complementos

Te invito a revisar mucha más información que puede ayudarte a desarrollar tus conocimientos en agilidad.

– Mejores Historias de Usuario para Scrum
https://softwareevolutivo.com.ec/mejores-historias-de-usuario-para-scrum/

– ¿La Agilidad puede ayudar a mi organización?
https://softwareevolutivo.com.ec/la-agilidad-puede-ayudar-a-mi-organizacion/

Fuentes

El presente blog, fue desarrollado en base a los conocimientos adquiridos en:

– “Curso de Fundamentos de Product Owner” de Platzi:
https://platzi.com/cursos/product-owner/

– Scrum Guide:

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf

The post Scrum: El rol del Product Owner appeared first on Software Evolutivo.