Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/iliangithub/proyecto_aws_2
https://github.com/iliangithub/proyecto_aws_2
aws aws-ec2 aws-route53 aws-s3 jdk mariadb-server maven memcached rabbitmq tomcat10
Last synced: 21 days ago
JSON representation
- Host: GitHub
- URL: https://github.com/iliangithub/proyecto_aws_2
- Owner: iliangithub
- Created: 2024-10-14T18:27:37.000Z (24 days ago)
- Default Branch: main
- Last Pushed: 2024-10-16T14:23:53.000Z (22 days ago)
- Last Synced: 2024-10-16T17:03:06.605Z (22 days ago)
- Topics: aws, aws-ec2, aws-route53, aws-s3, jdk, mariadb-server, maven, memcached, rabbitmq, tomcat10
- Homepage:
- Size: 169 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# 0.0 Proyecto Multi-Tier web APP ("delta")(IaaS).
El proyecto, se llama "delta", utiliza una estrategia para migrar los datos a la nube **lift&shift**, el "workload" o la carga de trabajo o conjunto de aplicaciones, procesos; es decir, el conjunto de recursos o sistemas que son trasladados a la nube sin modificar su arquitectura o funcionamiento.
Y transladado en AWS Cloud.
> [!TIP]
> #### ¿Qué es Lift and Shift?
> https://cloud.google.com/learn/cloud-migration?hl=es
>
> La **estrategia de "Lift and Shift"** es un enfoque común en la migración a la nube, donde las aplicaciones y servicios se trasladan desde un entorno local (on-premises) o de un proveedor de nube a otro sin realizar cambios significativos en su arquitectura o código.
>
>**Características principales:**
>- **Sin modificación del código**: En lugar de rediseñar o refactorizar la aplicación para aprovechar las capacidades específicas de la nube, simplemente se mueve tal como está.
>- **Migración rápida**: Esta estrategia es más rápida que otras porque no implica una reescritura importante de la aplicación.
>- **Reducción de costos iniciales**: Puede ser menos costoso al inicio, ya que no requiere una inversión significativa en desarrollo o reingeniería de la aplicación.
>- **Uso de infraestructura como servicio (IaaS)**: Normalmente, en lugar de utilizar servicios nativos de la nube (como PaaS o SaaS), las instancias o máquinas virtuales de la aplicación se migran a una infraestructura virtualizada similar (como EC2 en AWS).
>
>**Ventajas:**
>- **Simplicidad**: Es una opción sencilla y rápida para mover aplicaciones a la nube.
>- **Menor riesgo**: Como no se cambia la aplicación, el riesgo de introducir errores es menor.
>- **Continuidad**: El enfoque garantiza que las aplicaciones se sigan ejecutando de la misma manera, por lo que no hay grandes interrupciones para los usuarios.
>
> **Desventajas:**
>- **No se optimiza para la nube**: La aplicación no se beneficia completamente de las capacidades nativas de la nube (como escalabilidad automática, optimización de costos, etc.).
>- **Costos a largo plazo**: Aunque es más barato inicialmente, puede ser más costoso con el tiempo debido a la falta de optimización.
>- **Rendimiento limitado**: Las aplicaciones no se ajustan para aprovechar las optimizaciones en rendimiento y recursos que ofrecen los servicios en la nube.
>
> **¿Cuándo utilizar "Lift and Shift"?**
Es una buena opción si quieres migrar rápidamente sin modificar tus aplicaciones o si el tiempo y el presupuesto son limitados. También se utiliza cuando una organización quiere hacer la transición a la nube de forma progresiva, con la idea de optimizar las aplicaciones después.
>
Estamos hablando de un proyecto "delta", que va a ser un multitier web application stack o también **pila de aplicación web de múltiples capas**
Es un diseño arquitectónico que organiza una aplicación en varias capas o niveles, donde cada capa cumple una función específica. Este modelo ayuda a separar las responsabilidades dentro de la aplicación, facilitando la escalabilidad, el mantenimiento y la flexibilidad.
Hosteamos y lo ejecutaremos en AWS, **para producción.**
#### El escenario:
Tenemos servicios de app que está corriendo o son ejecutados en maquinas virtuales o físicas, servicios de base de datos; Postgre, Oracle, aplicaciones como; TomCat, LAMP stack y servicios DNS.
Tenemos este Workload, todos estos servidores corriendo de forma local, almacenar todo de forma local pues supone costes y no está automatizado, perdemos tiempo. Es decir, pagamos por la infraestructura como servicio, realmente pagamos del AWS pues la infraestructura, los procesadores, la RAM. IaaS. Es escalable, reducir o aumentar para reducir costes y rendimiento o aumentar el rendimiento pero también aumentar los costes y también podemos autimatizar.
Utilizamos evidengemente AWS Cloud Computing.
- Utilizaremos las instancias EC2, que serán nuestras máquinas virtuales, para nuestro TomCat, RabbitMQ, MemCache y MySQL.
- ELB para hacer un balanceador de carga, es decir, remplazaremos el Nginx como nuestro balanceador de cargas, ya no lo vamos a utilizar.
- El servicio de autoescalado, que automáticamente escalará o reducirá, según nuestras necesidades, que controlará nuestros recursos y nuestros costes.
- Y como almacenamiento, utilizaré el S3 y el EFS
- Por último, Route 53, para nuestro servicio DNS privado.
- También otros servicios como IAM, ACM o EBS.
entonces, queremos que sea flexible, escalable, e ir pagando de poco a poco por lo que vamos utilizando. Y también queremos automatización de la infra, IaaC.
## 0.1 El diseño arquitectura:
### 0.1.1 Resumen técnico, rápido:
#### Security Group:
| NAME: |
|---|
| delta-ELB-SG |
| delta-TomCat-APP-SG |
| delta-Backend-SG |
| REGLAS DE ENTRADA: delta-ELB-SG | |
|---|---|
| http: 80 | from: 0.0.0.0 /0 |
| https: 443 | from: 0.0.0.0 /0 |
| REGLAS DE ENTRADA: delta-TomCat-APP-SG | |
|---|---|
| ssh: 22 | from: My IP |
| http: 8080 | from: My IP |
| https: 443 | from: delta-ELB-SG |
| REGLAS DE ENTRADA: delta-Backend-SG | |
|---|---|
| ssh: 22 | from: My IP |
| SQL/Aurora: 3306 | from: delta-TomCat-APP-SG |
| TCP personalizado: 11211 | from: delta-TomCat-APP-SG |
| TCP personalizado: 5672 | from: delta-TomCat-APP-SG |
| Todo el tráfico | from: delta-Backend-SG **(sí mismo)** |
> [!TIP]
>Esta última regla, primero se crea el SG, y luego otra vez vuelves a editarlo para crear esa última regla de entrada del Backend-SG.
>
#### KEY PAIR:
| NAME: | TIPO DE PAR-CLAVE: | FORMATO |
|---|---|---|
| delta-parclave-produccion | RSA | .pem |
#### S3 KEY-ACCESS (Para acceder desde el CLI, user S3_admin):
Primero tienes que crear el usuario S3_admin. **(APARTADO 5.2).**
| CASO DE USO: | Establecer el valor de etiqueta de descripción: |
|---|---|
| Interfaz de comandos CLI| (nada) |
#### EC2 Instances:
| NAME: | SECURITY GROUP: | KEY-PAIR: | AMI: | TYPE: |
|---|---|---|---|---|
| delta-TomCat-app01 | delta-TomCat-APP-SG | delta-parclave-produccion | Ubuntu 24.04 | t2.micro |
| delta-rmq01 | delta-Backend-SG | delta-parclave-produccion | Amazon | t2.micro |
| delta-mc01 | delta-Backend-SG | delta-parclave-produccion | Amazon | t2.micro |
| delta-db01 | delta-Backend-SG | delta-parclave-produccion | Amazon | t2.micro |
#### ELB:
| TIPO: | NAME: | ZONAS DE DISPONIBILIDAD | SECURITY GROUP: |
|---|---|---|---|
| Balanceador de carga de aplicaciones | delta-produccion-ELB | Todas | delta-ELB-SG |
#### Auto Scaling Group:
- AMI de la instancia (app01).
- La plantilla de lanzamiento de la instancia.
- Grupo de autoescalado.
efs s3
#### EBS, para almacenar las instancias.
#### S3, para almacenar el artefacto, construido por Maven.
amazon certificate mana
#### Route 53, Servidor DNS
- Zona: delta.es
- Registro de la Zona: db01.delta.es
- Registro de la Zona: rmq01.delta.es
- Registro de la Zona: mc01.delta.es
### 0.1.2 La Arquitectura, visual:
### 0.1.3 Explicación de la Arquitectura:
Nuestros usuarios, van a acceder al sitio web, utilizando una URL y esa URL, va a apuntar al balanceador de carga.
>[!IMPORTANT]
>
> - La URL puede ser una URL de verdad, con un nombre de dominio de verdad, comprado.
> (NECESITAMOS USAR HTTPS, 443, PAGAR EL DOMINIO).
>
> - O podemos, simplemente usar el **nombre de dominio** del **Balanceador de carga ELB**
> (NECESITAMOS USAR HTTP, 80, NO PAGAR NINGÚN DOMINIO).
Si utilizamos, https, y habrá un certificado que será respaldado por el ACM de amazon (Amazon Certificate Manager).
Y si no, pues eso, simplemente accederemos desde el nombre de dominio del ELB.
El balanceador de carga, va a estar en un Grupo de Seguridad (Firewall) y solo aceptará peticiones https, solo tráfico https o también peticiones http, sólo tráfico http.
(En mi caso, he puesto las dos reglas, que acepte los dos tipos).
Entonces, el balanceador carga, mandará la petición a la instancia `app01` (TomCat), este TomCat, en realidad, tendrá varias instancias o puede tener varias, y serán pues manejadas por el grupo de autoescalado.
Al **principio crearemos SÓLO UNA INSTANCIA**, a raíz de esa, crearemos una AMI, la plantilla y **AL FINAL** pues el Grupo de Escalado, ASG.
Entonces, dependiendo del tráfico y las peticiones y recursos, pues escalará o reducirá, **AUTOMÁTICAMENTE**.
Estas instancias, pues estarán en otro grupo de de seguridad y solo aceptarán tráfico en el puerto 8080 y solo del balanceador de carga, ahora.
Necesitamos el backend, el MySQL, MemCache y RabbitMQ, las IP de estos servidores del backend, o los servicios, van estar pues en Route 53, en el DNS privado.
Lo primero que vamos a hacer, es crear los pares-clave, crear los grupos de seguridad, y vamos a iniciar las instancias con sus respectivos scripts, para que se inicien y configuren.
Vamos a actualizar la IP al name mapping en Route 53.Y finalmente, vamos a crear nuestra aplicación en código fuente, esto en nuestra máquina local (Terraform).
Y finalmente vamos a subir neustro artefacto a S3 bucket. Desde S3, vamos a descargarlo a la instancia EC2.
Luego, el ELB con HTTPS el certificado. EL balanceador de carga, irá pues a la página.
# 1.0 Grupos de Seguridad y Pares-Clave.
Sabiendo ya como va a ser el proyecto, pues empezamos primero por esto, empezamos por los Grupos y Claves, porque es una buena práctica.
## 1.1 Grupos de Seguridad (Creación).
Las de salida, como de costumbre no las vamos a tocar.
Ahora voy a crear las de la instancia TomCat:
y solo falta un último grupo de seguridad, para las aplicciones del backend:
**Y una vez creada, volvemos a editar esa misma**
Porque queremos añadir otra regla de entrada que admita el tráfico, de si mismo.
Y también tendríamos que haber añadido el puerto 22 SSH, en el TomCat app:
Con el backend, exatamente igual:
## 1.2 Pares-Claves (Creación).
# 2.0 Crear las instancias.
Vamos a clonar el source code
## 2.1 Para la base de datos, MariaDB:
**Nombre y etiquetas:**
| Clave | Valor |
| -------- | ------- |
| Name | proyecto-db01 |
| Project | delta |
**Imagenes de Aplicaciones y Sistemas Operativos (AMI)**
Amazon Linux, 2023, 64 bits (x86)
**Tipo de instancia**
t2.micro
**Pares clave**
Las que creamos `proyecto-produccion-pares-clave`
**Configuraciones de red**
Seleccionamos un grupo de seguridad existente: `proyecto-backend-SG`
**Detalles Avanzados > Datos de usuario**
```
#!/bin/bash
DATABASE_PASS='admin123'
sudo yum update -y
#sudo yum install epel-release -y
sudo yum install git zip unzip -y
sudo dnf install mariadb105-server -y
# starting & enabling mariadb-server
sudo systemctl start mariadb
sudo systemctl enable mariadb
cd /tmp/
git clone -b main https://github.com/hkhcoder/vprofile-project.git
#restore the dump file for the application
sudo mysqladmin -u root password "$DATABASE_PASS"
sudo mysql -u root -p"$DATABASE_PASS" -e "ALTER USER 'root'@'localhost' IDENTIFIED BY '$DATABASE_PASS'"
sudo mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1')"
sudo mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.user WHERE User=''"
sudo mysql -u root -p"$DATABASE_PASS" -e "DELETE FROM mysql.db WHERE Db='test' OR Db='test\_%'"
sudo mysql -u root -p"$DATABASE_PASS" -e "FLUSH PRIVILEGES"
sudo mysql -u root -p"$DATABASE_PASS" -e "create database accounts"
sudo mysql -u root -p"$DATABASE_PASS" -e "grant all privileges on accounts.* TO 'admin'@'localhost' identified by 'admin123'"
sudo mysql -u root -p"$DATABASE_PASS" -e "grant all privileges on accounts.* TO 'admin'@'%' identified by 'admin123'"
sudo mysql -u root -p"$DATABASE_PASS" accounts < /tmp/vprofile-project/src/main/resources/db_backup.sql
sudo mysql -u root -p"$DATABASE_PASS" -e "FLUSH PRIVILEGES"
sudo systemctl restart mariadb
```
## 2.2 Para el Memcached:
**Nombre y etiquetas:**
| Clave | Valor |
| -------- | ------- |
| Name | proyecto-mc01 |
| Project | delta |
**Imagenes de Aplicaciones y Sistemas Operativos (AMI)**
Amazon Linux, 2023, 64 bits (x86)
**Tipo de instancia**
t2.micro
**Pares clave**
Las que creamos `proyecto-produccion-pares-clave`
**Configuraciones de red**
Seleccionamos un grupo de seguridad existente: `proyecto-backend-SG`
**Detalles Avanzados > Datos de usuario**
```
#!/bin/bash
sudo dnf install memcached -y
sudo systemctl start memcached
sudo systemctl enable memcached
sudo systemctl status memcached
sed -i 's/127.0.0.1/0.0.0.0/g' /etc/sysconfig/memcached
sudo systemctl restart memcached
sudo yum install firewalld -y
sudo systemctl start firewalld
sudo systemctl enable firewalld
firewall-cmd --add-port=11211/tcp
firewall-cmd --runtime-to-permanent
firewall-cmd --add-port=11111/udp
firewall-cmd --runtime-to-permanent
sudo memcached -p 11211 -U 11111 -u memcached -d
```
## 2.3 Para el RabbitMQ:
**Nombre y etiquetas:**
| Clave | Valor |
| -------- | ------- |
| Name | proyecto-rmq01 |
| Project | delta |
**Imagenes de Aplicaciones y Sistemas Operativos (AMI)**
Amazon Linux, 2023, 64 bits (x86)
**Tipo de instancia**
t2.micro
**Pares clave**
Las que creamos `proyecto-produccion-pares-clave`
**Configuraciones de red**
Seleccionamos un grupo de seguridad existente: `proyecto-backend-SG`
**Detalles Avanzados > Datos de usuario**
```
#!/bin/bash
## primary RabbitMQ signing key
rpm --import 'https://github.com/rabbitmq/signing-keys/releases/download/3.0/rabbitmq-release-signing-key.asc'
## modern Erlang repository
rpm --import 'https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-erlang.E495BB49CC4BBE5B.key'
## RabbitMQ server repository
rpm --import 'https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-server.9F4587F226208342.key'
curl -o /etc/yum.repos.d/rabbitmq.repo https://raw.githubusercontent.com/hkhcoder/vprofile-project/aws-LiftAndShift/al2023rmq.repo
dnf update -y
## install these dependencies from standard OS repositories
dnf install socat logrotate -y
## install RabbitMQ and zero dependency Erlang
dnf install -y erlang rabbitmq-server
systemctl enable rabbitmq-server
systemctl start rabbitmq-server
sudo sh -c 'echo "[{rabbit, [{loopback_users, []}]}]." > /etc/rabbitmq/rabbitmq.config'
sudo rabbitmqctl add_user test test
sudo rabbitmqctl set_user_tags test administrator
sudo systemctl restart rabbitmq-server
```
## 2.4 Para la TomCat-app01:
**Nombre y etiquetas:**
| Clave | Valor |
| -------- | ------- |
| Name | proyecto-app01 |
| Project | delta |
**Imagenes de Aplicaciones y Sistemas Operativos (AMI)**
Ubuntu Server 24.04 LTS, 64 bits (x86)
**Tipo de instancia**
t2.micro
**Pares clave**
Las que creamos `proyecto-produccion-pares-clave`
**Configuraciones de red**
Seleccionamos un grupo de seguridad existente: `proyecto-TomCat-APP-SG`
**Detalles Avanzados > Datos de usuario**
```
#!/bin/bash
sudo apt update
sudo apt upgrade -y
sudo apt install openjdk-11-jdk -y
#sudo apt install tomcat9 tomcat9-admin tomcat9-docs tomcat9-common git -y
# no funciona Package tomcat9 is not available, but is referred to by another package.
#This may mean that the package is missing, has been obsoleted, or
#is only available from another source
#este si:
sudo apt install tomcat10 tomcat10-admin tomcat10-docs tomcat10-common git -y
sudo systemctl start tomcat10
# esto sirve para ahorrarnos un paso más adelante y automatizar
#para descargar el cli del aws
sudo apt install unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
```
# 3.0 Comprobaciones (podría fallar o haber errores).
## 3.1 Máquina MySQL.
```
sudo systemctl status mariadb
```
Evidentemente, tiene que mostrar que está running.
```
mysql -u admin -padmin123 accounts
```
Y deberías de ver esto:
```
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.25-MariaDB MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [accounts]>
```
```
SHOW tables;
```
Debería devolver esto:
| Tables_in_accounts |
| -------- |
| role |
| user |
| user_role |
Para salir del MariaDB:
```
quit
```
A por la siguiente máquina.
## 3.2 Máquina MemCache.
```
[ec2-user@ip-172-31-xx-xx ~]$ ss -tunlp | grep 11211
tcp LISTEN 0 1024 0.0.0.0:11211 0.0.0.0:*
tcp LISTEN 0 1024 [::1]:11211 [::]:*
```
## 3.3 Máquina RabbitMQ-server.
```
[ec2-user@ip-172-31-38-8 ~]$ systemctl status rabbitmq-server
● rabbitmq-server.service - RabbitMQ broker
Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; enabled; >
Active: active (running) since Tue 2024-10-15 09:19:03 UTC; 37min ago
Main PID: 26089 (beam.smp)
Tasks: 26 (limit: 1112)
Memory: 68.1M
CPU: 5.748s
CGroup: /system.slice/rabbitmq-server.service
├─26089 /usr/lib64/erlang/erts-14.2.5.4/bin/beam.smp -W w -MBas ag>
├─26102 erl_child_setup 32768
├─26117 sh -s disksup
├─26119 /usr/lib64/erlang/lib/os_mon-2.9.1/priv/bin/memsup
├─26120 /usr/lib64/erlang/lib/os_mon-2.9.1/priv/bin/cpu_sup
├─26121 /usr/lib64/erlang/erts-14.2.5.4/bin/inet_gethost 4
├─26122 /usr/lib64/erlang/erts-14.2.5.4/bin/inet_gethost 4
├─26133 /usr/lib64/erlang/erts-14.2.5.4/bin/epmd -daemon
└─26152 /bin/sh -s rabbit_disk_monitor
```
## 3.4 Máquina TomCat-app01.
```
systemctl status tomcat10
```
```
● tomcat10.service - Apache Tomcat 10 Web Application Server
Loaded: loaded (/usr/lib/systemd/system/tomcat10.service; enabled; preset:>
Active: active (running) since Tue 2024-10-15 10:10:20 UTC; 2min 26s ago
Docs: https://tomcat.apache.org/tomcat-10.0-doc/index.html
Process: 5223 ExecStartPre=/usr/libexec/tomcat10/tomcat-update-policy.sh (c>
Main PID: 5228 (java)
Tasks: 28 (limit: 1130)
Memory: 104.9M (peak: 112.4M)
CPU: 6.126s
CGroup: /system.slice/tomcat10.service
└─5228 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -Djava.util.log>
Oct 15 10:10:46 ip-172-31-40-172 tomcat10[5228]: At least one JAR was scanned f>
Oct 15 10:10:46 ip-172-31-40-172 tomcat10[5228]: Deployment of deployment descr>
Oct 15 10:10:46 ip-172-31-40-172 tomcat10[5228]: Deploying deployment descripto>
Oct 15 10:10:46 ip-172-31-40-172 tomcat10[5228]: The path attribute with value >
Oct 15 10:10:46 ip-172-31-40-172 tomcat10[5228]: At least one JAR was scanned f>
Oct 15 10:10:46 ip-172-31-40-172 tomcat10[5228]: Deployment of deployment descr>
Oct 15 10:10:56 ip-172-31-40-172 tomcat10[5228]: Deploying deployment descripto>
Oct 15 10:10:56 ip-172-31-40-172 tomcat10[5228]: The path attribute with value >
Oct 15 10:10:57 ip-172-31-40-172 tomcat10[5228]: At least one JAR was scanned f>
Oct 15 10:10:57 ip-172-31-40-172 tomcat10[5228]: Deployment of deployment descr
LUEGO
ls /var/lib/tomcat10/
conf lib logs policy webapps work
Y WEBAPPS ES DONDE VAN A ESTAR PUES LAS APPS WEB.
```
Este es nuestro archivo /etc/hosts:
> [!IMPORTANT]
> El archivo /etc/hosts es útil en situaciones locales o para configuraciones muy específicas en servidores individuales, ya que permite mapear nombres de dominio a direcciones IP de forma local en la máquina. Sin embargo, no es una solución viable para entornos de producción o en la nube, especialmente en AWS.
>
> (Mapear = asociar un nombre de dominio a una dirección IP)
>
> ### 3.4.1 ¿Por qué solo sirve de forma local el archivo /etc/hosts?
>El archivo /etc/hosts es un archivo de configuración presente en sistemas Unix y Linux, que permite hacer este mapeo de manera local en una máquina específica. Es local porque solo afecta esa máquina en particular; cualquier otro dispositivo (como el de un cliente externo) no verá ni usará los cambios que realices en ese archivo.
>
>**Cada máquina tiene su propio archivo /etc/hosts: Cada vez que una máquina necesita traducir un dominio a una IP, primero revisa su propio archivo /etc/hosts antes de hacer consultas a servidores DNS. Esto significa que cualquier cambio en este archivo solo será visible para esa máquina en particular.**
>
>No se comparte a nivel de red. **Los cambios que realices en el archivo /etc/hosts no se propagan ni se comunican a otras máquinas en la red o en internet**. Si otras máquinas o usuarios quieren resolver el mismo nombre de dominio, **deberán tener sus propios mapeos o depender de un servidor DNS.**
>
>Limitado a resoluciones locales: En redes pequeñas o entornos de desarrollo, el archivo /etc/hosts puede ser útil si necesitas probar algo rápidamente o hacer una configuración temporal. Sin embargo, en entornos de producción (como en AWS), donde muchos usuarios deben acceder a tu instancia o servicio, necesitas un sistema centralizado de resolución de nombres como Route 53, que es un servidor DNS.
>
>### 3.4.2 ¿Por qué necesitas un servidor DNS como Route 53?
>Cuando quieres que tu dominio sea accesible para cualquier persona en internet (porque no tienen tu archivo /etc/hosts/), los navegadores y sistemas operativos de los usuarios no van a consultar tu archivo /etc/hosts. **En su lugar, consultan servidores DNS distribuidos por todo el mundo**. Route 53 es un servicio de DNS que permite gestionar estos mapeos de forma centralizada y global, permitiendo que cualquier persona pueda acceder a tu dominio, no solo una máquina local.
>
# 4.0 Route 53 (DNS Server).
Así que buscamos en la consola de AWS, el servicio Route 53:
Tenemos que crear una zona, y allí estará nuestro nombre de dominio. Y en ese dominio, tendremos diferentes Hosts. Y esos registros de Hosts, tendrán la IP o el CNAME.
## 4.1 Crear Zona.
> [!TIP]
> Una zona DNS es una porción del espacio de nombres DNS que se administra de manera independiente. Puede contener uno o varios registros DNS y puede abarcar un dominio completo o una subparte de él.
>
Y vamos a ponerle nombre de dominio: `delta.es`
NO VA A SER RESUELTO DESDE EL INTERNET, DESDE FUERA.
VPC, es la Red, de esa región:
## 4.2 Crear Registros.
Y ahora creamos un "record", un registro:
necesito saber la IP privada de mis instancias:
Y lo copio en el registro:
Y creamos el registro. Ahora hacemos lo mismo con el resto.
> [!TIP]
> **ESTO ES OPCIONAL.**
>
> En mi caso, la interfaz me aparece así:
>
>
>
> Si cambiamos el asistente, se verá de esta forma más compleja:
>
> 
>
> 
>
> Y le damos a definir un registro simple.
>
> 
Realmente, solamente necesitamos estos 3 registros, no más. Porque la aplicacción se va a conectar a estos servicios backend.
# 5.0 Construir y Desplegar el artefacto.
> [!TIP]
> En DevOps, un artefacto se refiere a cualquier archivo generado durante el proceso de desarrollo de software que puede ser usado en las siguientes fases del ciclo de vida del software. Los artefactos son los resultados tangibles del proceso de construcción y despliegue de una aplicación.
>
Y seleccionamos GitBash.
> [!WARNING]
> GitBash ahora es el terminal por defecto.
>
Como podemos ver, ahora, si intento abrir la terminal, pues me abre la de GitBash:
tenemos que modificar esta parte:
y así pues añadir el registro DNS. Este es el resultado, lo tenemos que hacer con los 3:
Y ahora, vamos a montar / construir el artefacto.
## 5.1 Construir el artefacto.
Prerequisitos:
- Maven
```
choco install maven -y
```
```
mvn --version
```
- JDK
```
choco install corretto11jdk -y
```
Son herramientas esenciales que se utilizan para montar y construir artefactos en el desarrollo de software, especialmente en proyectos de Java.
- AWS CLI
```
choco install awscli -y
```
>[!WARNING]
>Hay que reiniciar el ordenador, si los acabas de instalar. Por que, muy probablemente, no funcionen.
>
Ahora, vamos a construir el artefacto:
Tenemos que estar en este directorio, he hecho un `ls` para que se vea:
```
mvn install
```
>
>### 5.1.1 Pasos que realiza `mvn install`:
>**Limpieza previa (si es necesario):**
>Si has configurado pasos de limpieza, como eliminar los artefactos anteriores, esto puede suceder antes de compilar.
>
>**Compilación (compile):**
>Maven compila el código fuente del proyecto (normalmente dentro del directorio src/main/java) y genera los archivos .class.
>
>**Pruebas (test):**
>Se ejecutan las pruebas unitarias (si tienes tests configurados, como en el directorio src/test/java). Maven usará frameworks de pruebas como JUnit o TestNG.
>
>**Empaquetado (package):**
>Maven empaqueta el proyecto en un archivo ejecutable, generalmente un JAR o WAR (dependiendo del tipo de proyecto). Este archivo contiene el código compilado y las dependencias.
>
>**Instalación (install):**
>En este paso, el artefacto generado (el JAR, WAR u otro empaquetado) se coloca en el repositorio local de Maven, que se encuentra en tu máquina, en el directorio ~/.m2/repository (o en la carpeta de >configuración de Maven si has cambiado la ruta). Esto permite que otros >proyectos que dependan de este artefacto lo puedan utilizar.
>
> [!IMPORTANT]
>**Maven guarda el artefacto compilado y empaquetado (por ejemplo, un archivo .jar o .war) en el subdirectorio target dentro del directorio raíz de tu proyecto.**
>
Tal y como se puede comprobar, efectivamente ha creado un directorio `target/` y dentro pues:
Ahora, voy a subir todo a S3 bucket.
> [!WARNING]
> no es posible sin la autenticación. Ya que vamos a tener que usar el AWS CLI, y tendrá que saber pues a que cuenta va a ir.
>
## 5.2 Crear un usuario IAM y subir el artefacto a S3 bucket.
Entonces, vamos a crear un usuario especial solo para acceder al S3 bucket. Por lo tanto vamos a darle SÓLO permisos para el S3 bucket.
Este va a ser el nombre, `S3_admin`:
No necesitamos, ningún acceso a la consola, solo necesitamos la clave de acceso y la clave privada.
Una vez creado, vamos al panel de usuarios, le damos click al `S3_admin`, luego a, credenciales de seguridad y bajamos para abajo hasta llegar a "claves de acceso". Y creamos:
Esta es la opción que queremos, pues es lo que vamos a hacer, usar el CLI del AWS:
También le tengo que dar a confirmar:
"Entiendo la recomendación anterior y deseo proceder a la creación de una clave de acceso".
> [!WARNING]
> **¿Cuál es el riesgo?**
>
NO voy a "establecer el valor de etiqueta de descripción" pues es opcional.
En el tercer y último paso, pues ya nos proporcionan las claves:
Descargo el .csv.
Ya tenemos las claves.
## 5.3 Subir el artefacto a S3 (Necesito autenticarme el par-claves anterior).
**Entonces, hemos creado un usuario `S3_admin`, que también está asociado pues a un par claves, es así como iniciamos sesión.**
**(NO vamos a utilizar, user y password)**
Y ahora en el CLI del Visual Studio:
```
aws configure
```
El S3 bucket, el nombre tiene que ser **100% único**, no como el mío, si no, como el de ningún otro:
```
aws s3 mb s3://forilianprojectbucket-delta
```
Y en teoría, con este comando, ya debería de estar:
```
aws s3 cp target/vprofile-v2.war s3://forilianprojectbucket-delta
```
Y ya debería haberse subido, vamos a comprobarlo, vamos a la barra de búsqueda de AWS y buscamos ``S3`
como podemos ver, aparece:
dentro, está el artefacto:
### 5.3.1 Descargar y Desplegar el artefacto (En la instancia TomCat).
Prerequisitos:
- El AWS CLI instalado **DENTRO DEL TomCat.**
- Descargarlo y desplegarlo.
> [!WARNING]
> **PROBLEMA:**
>
>¿Cómo vamos a autenticarnos ahora, desde el TomCat, para poder descargar desde el S3 bucket?
>
>Anteriormente, utilizamos el AWS CLI y utilizamos las claves IAM para poder autenticarme, al Usuario ese en cuestión que creamos en el IAM, para poder "pushear", subir el artefacto.
>
> Podríamos volver a hacerlo de esa misma manera (Es más larga y compleja).
> Y es a través de los Roles IAM.
> Creamos un Rol y ponemos/adjuntamos, ese rol a la instancia.
>
El permiso:
Y le ponemos este nombre:
Lo creamos, volvemos a la instancia y editamos:
Le atribuimos el rol:
Como tenemos privilegios asociados a esta instancia, podemos ejecutar el comando de AWS, sin tener que autenticarnos:
```
aws s3 cp s3://forilianprojectbucket-delta/vprofile-v2.war /tmp/
```
```
sudo systemctl stop tomcat10
```
```
sudo rm -rf /var/lib/tomcat10/webapps/ROOT
```
```
sudo cp /tmp/vprofile-v2.war /var/lib/tomcat10/webapps/ROOT.war
```
```
sudo systemctl daemon-reload
```
```
sudo systemctl start tomcat10
```
# 6.0 Balanceador de Carga, ELB.
Requisito:
## 6.1 Crear el Target Group.
Estamos en EC2 y vamos a crear un "Target Group".
Le ponemos un nombre, y cambiamos el puerto a 8080.
Y creamos el grupo de destino o el Target Group.
## 6.2 Crear el Balanceador de Carga
> [!WARNING]
>
>Debe escuchar en el puerto 80 y 443 (443 opcional si tengo dominio).
>
> 
>
>(Para que funcione el HTTPS)
>
>
>
> Esto obligado a poner el Certificado, si he puesto listener en el puerto 443, por lo tanto, voy a tener que quitarlo de momento, luego lo añadiré.
>
Una vez esté hecho el balanceador.
## 6.3 Comprobar que funcione el ELB.
Copiamos el enlace:
Y este enlace, tenemos que pegarlo en el navegador.
**Este es el resultado:**
> [!WARNING]
> ### Error, TomCat.
> Si nos sale algún tipo de error, es muy probable que sea por algo relacionado con el TomCat, hasta el momento, si se ha seguido todo al pié de la letra, es muy sencillo y automático, las máquinas están >provisionadas, y no debería de haber problema en ese sentido.
>
> **NOS APARECERÁ ESTO, EN CASO DE QUE NO HAYAMOS PUESTO LA PÁGINA:**
> 
>
> ```
> ● tomcat10.service - Apache Tomcat 10 Web Application Server
> Loaded: loaded (/usr/lib/systemd/system/tomcat10.service; enabled; preset: enabled)
> Active: active (running) since Tue 2024-10-15 19:33:56 UTC; 3min 1s ago
> Docs: https://tomcat.apache.org/tomcat-10.0-doc/index.html
> Process: 12013 ExecStartPre=/usr/libexec/tomcat10/tomcat-update-policy.sh (code=exited, status=0/SUCCESS)
> Main PID: 12018 (java)
> Tasks: 28 (limit: 1130)
> Memory: 78.4M (peak: 78.6M)
> CPU: 3.816s
> CGroup: /system.slice/tomcat10.service
> └─12018 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -Djava.util.logging.config.file=/var/lib/tomcat10/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dja>
>
>Oct 15 19:33:58 ip-172-31-40-172 tomcat10[12018]: OpenSSL successfully initialized [OpenSSL 3.0.13 30 Jan 2024]
>Oct 15 19:33:59 ip-172-31-40-172 tomcat10[12018]: Initializing ProtocolHandler ["http-nio-8080"]
>Oct 15 19:33:59 ip-172-31-40-172 tomcat10[12018]: Server initialization in [1896] milliseconds
>Oct 15 19:33:59 ip-172-31-40-172 tomcat10[12018]: Starting service [Catalina]
>Oct 15 19:33:59 ip-172-31-40-172 tomcat10[12018]: Starting Servlet engine: [Apache Tomcat/10.1.16 (Ubuntu)]
>Oct 15 19:33:59 ip-172-31-40-172 tomcat10[12018]: Deploying web application directory [/var/lib/tomcat10/webapps/ROOT]
>Oct 15 19:34:01 ip-172-31-40-172 tomcat10[12018]: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs wer>
>Oct 15 19:34:01 ip-172-31-40-172 tomcat10[12018]: Deployment of web application directory [/var/lib/tomcat10/webapps/ROOT] has finished in [1,760] ms
>Oct 15 19:34:01 ip-172-31-40-172 tomcat10[12018]: Starting ProtocolHandler ["http-nio-8080"]
>Oct 15 19:34:01 ip-172-31-40-172 tomcat10[12018]: Server startup in [1871] milliseconds
> ```
> **SIN EMBARGO, AL METER LA PÁGINA NOS APARECE ESTE ERROR:**
> Y simplemente, tenemos que meter de nuevo allí el artefacto. En la carpeta de TomCat, "webapps"
>
> 
>
> Anteriormente, ejecuté al TomCat, sin nada, y funciona, ahora este es el resultado cuando pongo MI página.
>
> En TomCat, me aparece este error al ejecutar `systemctl status tomcat10`
>
>
>
> [!WARNING]
> ### Error 2, no puedo acceder desde el navegador.
>
> Entonces, contexto, he apagado las máquinas, dia nuevo, enciendo las máquinas, copio el enlace, ya no puedo acceder. ¿Por qué?
>
> 
>
> #### OPCIÓN DESCARTADA 1
> Sé que las IP's privadas de mis instancias, no han cambiado, por lo tanto, no hay conflicto con LOS REGISTROS DE LA ZONA DNS:
>
> 
>
> - db01:
>
> 
>
> - rmq01:
>
> 
>
> - mc01:
>
> 
>
> #### OPCIÓN DESCARTADA 2
>
> Hay una regla de seguridad, TomCat-APP-SG
>
>
>
> En la que selecciono "My IP", se coloca la IP pública
>
> **¿Pero no era de hecho la IP pública la que variaba CUANDO APAGO LA MÁQUINA? ¿Se modifica también automáticamente del Security Group? ¿O solo se modifica de la instancia?**
>
> 
>
> Como podemos ver, la IP pública es la `54.205.223.115`
>
> Entonces, **EFECTIVAMENTE NO COINCIDEN Y HAY QUE REFRESCARLAS MANUALMENTE:**
>
> 
>
> #### OPCIÓN 3 (la correcta)
>
> TENGO QUE ACCEDER DESDE EL BALANCEADOR DE CARGA, Y NO DIRECTAMENTE DESDE EL NOMBRE DE DOMINIO DEL TOMCAT-APP01
>
> 
>
>
# 7.0 Grupoo de Autoescalado (Autoscaling Group).
Entonces, lo que queremos es básicamente escalar o reducir, dependiendo de la carga.
Requisitos:
- AMI de la instancia.
- La plantilla de lanzamiento de la instancia.
- El grupo de autoescalado.
## 7.1 Crear la AMI:
Desde el EC2, buscamos la instancia y le damos a crear imagen:
La llamaré `delta-app01-tomcat-image`.
El resto de cosas, no hay que tocarlas.
Debemos esperar a que ponga "Disponible".
## 7.2 Crear la plantilla:
Ahora, nos vamos a Launch Templates y la creamos:
Selecciono la AMI:
## 7.3 Crear Grupo de Autoescalado:
### 7.4 Comprobación:
Como podemos comprobar funciona:
(OPCIONAL)
# 8.0 Final, formas alternativas de hacerlo (PaaS y SaaS):