Blog de Amazon Web Services (AWS)

Modernice sus aplicaciones Java en Oracle Weblogic usando AWS App2Container

Por Christian Castro, Senior Solutions Architect en AWS

 

La transformación digital se ha convertido sin duda en la pieza clave del éxito de muchas empresas en el mercado, tanto para acelerar el time-to-market, como para disminuir costos, mejorar la calidad de sus productos y operaciones y además estar más cerca de sus clientes. En AWS estamos conscientes de ellos, y queremos que nuestros clientes disminuyan el tiempo para llegar a esa transformación.

Los contenedores son un habilitador tecnológico que ha permitido a nuestros clientes conseguir transformarse al aprovechar beneficios de portabilidad, desacoplamiento de tecnologías, optimización de costos, entre otros. AWS lanzó el servicio de App2Container, que es una herramienta de línea de comandos con la que ayudamos a nuestros clientes a modernizar sus aplicaciones Java y .NET en imágenes de contenedores.

 

Consideraciones

Las mejores prácticas de arquitectura que define la metodología “twelve-factor” establecen, entre otras cosas, que para el despliegue y desarrollo de aplicaciones web debemos declarar y aislar explícitamente cualquier dependencia, por ello trataremos de evitar cualquier dependencia tecnológica que orille a sus aplicaciones a generar altos grados de acoplamiento.

Tal vez habrá escenarios en los que prefiera trabajar arquitecturas de transición, hasta llegar al punto ideal de modernización de sus aplicaciones, y una de esas arquitecturas implique el uso de contenedores para la infraestructura de su software. Por ejemplo, puede definir una estrategia tecnológica en la que su arquitectura objetivo (To-Be) sea un ecosistema de microservicios sobre infraestructura serverless, y su arquitectura actual (As-Is) sea un grupo de aplicaciones monolíticas en Java desplegadas en servidores de aplicaciones empresariales como Oracle Weblogic. Una buena consideración en sus arquitecturas de transición sería seguir los siguientes pasos: declarar y aislar explícitamente las dependencias, guardar la configuración en el entorno, y buscar un esquema de desacoplamiento de esa infraestructura a través del uso de contenedores orquestados en la nube de AWS. Con esto usted puede empezar a aprovechar beneficios a corto plazo, mientras su equipo de desarrollo y operaciones trabaja en una segunda arquitectura de transición que lo haga llegar a sus objetivo final, que es el despliegue de microservicios en infraestructura serverless.

En este blog ejemplificaremos cómo usted puede utilizar AWS App2Container para el proceso de modernización de una aplicación Java desplegada en Oracle Weblogic 12c. Dada la explicación de los párrafos anteriores, no estamos asumiendo un escenario de despliegue en clúster sobre Weblogic, ni la instalación o dependencia de algún otro componente de Oracle como Oracle Coherence u Oracle Access Management, por mencionar algunos.

En la práctica no siempre las empresas tienen oportunidad de instalar componentes en servidores en producción, por lo que en este blog consideraremos el uso de los comandos de uso remoto de App2Container. Para esto utilizaremos una infraestructura intermedia, también llamada máquina de trabajo o worker machine en inglés, mediante la cual ejecutaremos los comandos de App2Container conectándonos de forma remota al servidor de Weblogic.

 


Figura 1. Modelo conceptual de la arquitectura ejemplo

 

En este ejemplo simularemos la aplicación legada en una instancia EC2 con Red Hat Enterprise Linux, sin embargo, los pasos pueden aplicar para cualquier infraestructura en donde se encuentre su aplicación sobre Weblogic.

Como infraestructura de despliegue en AWS, vamos a utilizar un clúster de contenedores orquestado por Amazon Elastic Kubernetes Service (EKS), pero también tiene la posibilidad de definir el servicio de Elastic Container Service (ECS) si así lo requiere.

 

Prerequisitos

Compruebe que ha completado los siguientes requisitos previos:

  • Ha verificado que su entorno de aplicación cumple con todos los requisitos de aplicaciones soportadas por App2Container.
  • Lanzó una instanciacomo máquina de trabajo. En este caso como referencia utilizaremos una instancia t3.large con un volúmen EBS de 200 GiB de tipo gp3. Para esta instancia se utilizará la última versión de Amazon Linux en su versión x86.
  • Instaló y configuró el perfil de AWS en su máquina de trabajo de acuerdo a la definición de políticas de IAM para despliegue desde App2Container.
  • Instaló el motor Docker en su máquina de trabajo.
  • El servidor de aplicaciones Weblogic se encuentra ejecutándose correctamente, y tiene habilitado el acceso al puerto 22 para la dirección IP de la máquina de trabajo.
  • Tiene acceso de root en el servidor Weblogic y en la máquina de trabajo.
  • El servidor Weblogic y la máquina de trabajo tienen tar y al menos 50 GB de espacio libre de almacenamiento.
  • Ha creado un bucket de Amazon S3 que utilizará App2Container para almacenar los artefactos generados con el comando extract.

Instalar y Configurar App2Container

App2Container para Linux está empaquetado como un archivo tar.gz. El archivo contiene un script de Shell interactivo que instala App2Container en su servidor. En este caso realizaremos la instalación de App2Container en la máquina de trabajo.

El objetivo es migrar el servidor de aplicaciones Weblogic hacia un clúster de Kubernetes sobre Amazon EKS. Para esta tarea utilizaremos App2Container para generar una imagen de contenedor de Weblogic, almacenarla en Amazon ECR y al final hacer el despliegue. A continuación un diagrama con el detalle de la solución.

 

Figura 2. Arquitectura del proceso de modernización

Para descargar e instalar App2Container para Linux

  1. Desde la máquina de trabajo, descargue el archivo de instalación utilizando el comando curl para descargar el paquete de instalación de App2Container.

curl -o AWSApp2Container-installer-linux.tar.gz https://app2container-release-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/AWSApp2Container-installer-linux.tar.gz

  1. Extraiga el paquete en una carpeta local del servidor.

sudo tar xvf AWSApp2Container-installer-linux.tar.gz

  1. Ejecute el script de instalación que extrajo del paquete y siga las indicaciones.

sudo ./install.sh

Puede comprobar la integridad del archivo de instalación tar.gz descargado validando los códigos hash MD5 y SHA256 del archivo local con los archivos hash publicados. Para mayor detalle de este procedimiento revise la documentación de AWS App2Container.

Inicializar y configurar App2Container

En el servidor máquina de trabajo ejecute el comando init como se muestra a continuación.

sudo app2container init

Se le pedirá que proporcione la siguiente información. Seleccione <enter> para aceptar el valor predeterminado.

  • Ruta del directorio del espacio de trabajo – Un directorio local donde App2Container pueda almacenar artefactos durante el proceso de contenerización. En este caso dejaremos el valor predeterminado que es /root/app2container.
  • Perfil de AWS – Contiene la información necesaria para ejecutar App2Container, como sus claves de acceso a AWS. Para este ejercicio se utilizará el perfil de AWS definido cuando se configuró el CLI, por lo que no se usará un Instance Profile.
  • Bucket de Amazon S3: Se debe proporcionar el nombre del bucket de Amazon S3 en el que puede extraer artefactos mediante el comando extract. El comando containerize utiliza los componentes extraídos para crear el contenedor de la aplicación si el bucket de Amazon S3 está configurado. En este caso utilice el nombre bucket que generó en los prerrequisitos de este blog, por ejemplo: app2-container-weblogic.
  • Permiso para recopilar métricas de uso – Puede permitir opcionalmente que App2Container recopile información sobre el sistema operativo del host, el tipo de aplicación y los comandos app2container que se ejecutan. Para los fines de este blog sugerimos permitir la recopilación de métricas.
  • Permiso para cargar automáticamente los registros y los artefactos generados por App2Container en caso de colisiones y errores internos – Dejar por defecto.
  • Si se deben imponer imágenes firmadas – Puede requerir opcionalmente que las imágenes sean firmadas usando Docker Content Trust (DCT). Para fines de este blog dejaremos el valor predeterminado, que es no.

A continuación, un ejemplo de la salida de la ejecución del comando anterior.

Workspace directory path for artifacts[default: /root/app2container]:
Use AWS EC2 Instance profile 'arn:aws:iam::-:instance-profile/MyEC2InstanceProfile' configured with this instance? (Y/N)[default: y]: N
AWS Profile (configured using 'aws configure --profile')[default: default]:
Optional S3 bucket for application artifacts: app2container-weblogic-dec-10
Report usage metrics to AWS? (Y/N)[default: y]:
Automatically upload logs and App2Container generated artifacts on crashes and internal errors? (Y/N)[default: y]:
Require images to be signed using Docker Content Trust (DCT)?

(Y/N)[default: n]:
Configuration saved

Configuración de conexión remota

App2Container utiliza AWS Secrets Manager como mejor práctica para administrar las credenciales para conectar su máquina de trabajo a los servidores de aplicaciones, en este caso el servidor Weblogic, con el fin de ejecutar comandos remotos. Secrets Manager cifra sus secretos para su almacenamiento y proporciona un nombre de recurso de Amazon (ARN) para que pueda acceder al secreto. Cuando ejecuta el comando de configuración remota, proporciona el ARN secreto para que App2Container lo utilice para conectarse a su servidor de destino al ejecutar el comando remoto. Para obtener más información sobre Secrets Manager, consulte ¿Qué es AWS Secrets Manager?

Esta guía de AWS Secrets Manager le dará el detalle de los pasos que debe seguir para configurar las credenciales de acceso a su servidor Weblogic.

A continuación lo que se debe realizar es la configuración de la ejecución de comandos remotos de App2Container.

Ejecute el siguiente comando desde la máquina de trabajo para configurar las conexiones necesarias para ejecutar flujos de trabajo remotos en el servidor remoto Weblogic.

sudo app2container remote configure 

Se le pedirá que proporcione la siguiente información. Seleccione <enter> para aceptar el valor predeterminado.

  • Dirección IP del servidor Weblogic: proporcione la dirección IP de su servidor Weblogic. Se requiere si el campo FQDN está vacío.
  • FQDN (nombre de dominio completo) del servidor: el nombre de dominio completo del servidor Weblogic, utilizado como identificador para la conexión. Si se utiliza una dirección IP como identificador del host, debe estar vacío. Si el FQDN tiene un valor, la dirección IP se ignora.
  • Método de autenticación a utilizar key/cert: Debe especificar el tipo de credencial a utilizar para conectarse a su servidor Weblogic, tiene las opciones de key para clave o cert para certificado. En este caso utilizaremos el valor key del usuario de Linux con el que accederemos al servidor Weblogic.
  • ARN secreto para las credenciales de conexión remota: Aquí debe de proporcionar el ARN del secreto generado en Secrets Manager tal y como se indica en el primer párrafo de esta sección.

A continuación, un ejemplo de la salida de la ejecución del comando anterior.

Server IP address: 10.10.10.10
Server FQDN (Fully Qualified Domain Name):
Authentication method to be used key/cert: key
Secret ARN for remote connection credentials: arn:aws:secretsmanager:us-west-2:123456789012:secret:linux-cert-Abcdef
Continue to configure servers? (y/N)[default: n]: n

👍 Configure successful, you can view hosts config file at: /root/.app2container-config/remote_hosts.conf

Descubrimiento y Análisis

Su proceso de modernización comienza con el descubrimiento de los procesos Java que ejecuta el servidor Weblogic, la creación de un inventario y el posterior análisis de este.

Obtener el inventario de los procesos Java

Ejecute el siguiente comando desde su máquina de trabajo para listar las aplicaciones que se están ejecutando en el servidor donde se encuentra instalado Weblogic. En este caso, suponiendo que el servidor Weblogic tuviera la dirección IP 10.10.10.10, el comando sería como se muestra a continuación.

sudo app2container remote inventory --target 10.10.10.10

La salida es una colección de objetos JSON con un nodo para cada aplicación. Cada objeto incluirá pares clave/valor y comenzará con el Java-app-id como se muestra a continuación.

Su salida será como la que se muestra a continuación.

✔ Server inventory has been stored under /root/app2container/remote/10.10.10.10/inventory.json

Al revisar el archivo JSON que se menciona en la salida del comando anterior, puede observar dos datos que inician con el nombre “java-generic…”

{
        "java-generic-3828c90a9007": {
                "processId": 10440,
                "cmdline": "/scratch/u01/app/jdk1.8.0_301/bin/java ... -da -Dwls.home=/home/oracle/wls12214/wlserver/server -Dweblogic.home=/home/oracle/wls12214/wlserver/server weblogic.Server ",
                "applicationType": "java-generic",
                "webApp": ""
        },
        "java-generic-8f7f33439066": {
                "processId": 10439,
                "cmdline": "/scratch/u01/app/jdk1.8.0_301/bin/java ... -classpath /home/oracle/wls12214/wlserver/common/derby/lib/derby.jar:/home/oracle/wls12214/wlserver/common/derby/lib/derbynet.jar:/home/oracle/wls12214/wlserver/common/derby/lib/derbytools.jar:/home/oracle/wls12214/wlserver/common/derby/lib/derbyoptionaltools.jar:/home/oracle/wls12214/wlserver/common/derby/lib/derbyclient.jar org.apache.derby.drda.NetworkServerControl start ",
                "applicationType": "java-generic",
                "webApp": ""
        }
}

Observe que en este caso la aplicación detectada con el identificador “java-generic-8f7f33439066” en su atributo cmdline muestra que corresponde a una base de datos Derby utilizada por el servidor de aplicaciones.

Si revisa el identificador “java-generic-3828c90a9007” verá que este sí corresponde al proceso Java que ejecuta el servidor Weblogic. Copie este identificador de aplicación en un bloc de notas ya que lo utilizará en los próximos pasos.

Analice la aplicación

A continuación, analice las dependencias en tiempo de ejecución del proceso de Weblogic que se está ejecutando, incluidos los procesos que cooperan y las dependencias de los puertos de red.

Utilice el ID de la aplicación de la salida JSON del comando de inventario y luego ejecute el comando “app2container analyze –application-id <java-app-id>” después de reemplazar <java-app-id> con el ID de la aplicación que ha anotado en el paso anterior.

sudo app2container remote analyze --application-id java-generic-3828c90a9007 --target 10.10.10.10 

La salida del comando anterior será algo como lo siguiente:

👍 Analysis successful for application java-generic-3828c90a9007
💡 Next Steps:
1. View the application analysis file at /root/app2container/remote/10.10.10.10/java-generic-3828c90a9007/analysis.json.
2. Edit the application analysis file as needed.
3. Start the extraction process using the following command: app2container remote extract --target 10.10.10.10 --application-id java-generic-3828c90a9007

Como puede ver, App2Container ha generado un archivo analysis.json con los datos del análisis realizado a las dependencias del proceso que ejecuta Weblogic en su servidor. Además, App2Container nos guía intuitivamente con los siguientes pasos para completar el proceso de conteinerización. Como primer paso vamos a revisar el archivo analysis.json para comprobar que todo está correcto.

Como puede ver, este archivo solamente debe ser editado en lo que abarca lo correspondiente al campo “containerParameters”. En el alcance de este ejercicio no debemos modificar nada en este campo. Como fin informativo, puede revisar el tipo de imagen de contenedor que será utilizado, que no estamos excluyendo ningún archivo, no se están definiendo ni logs ni dependencias extras, y que se está tomando como puerto principal el 7001, que es el puerto por defecto del Admin Server de Weblogic.

"containerParameters": {
              "_comment1": "*** EDITABLE: The below section can be edited according to the application requirements. Please see the analysisInfo section below for details discovered regarding the application. ***",
              "imageRepository": "java-generic-3828c90a9007",
              "imageTag": "latest",
              "containerBaseImage": "registry.access.redhat.com/ubi8/ubi",
              "appExcludedFiles": [],
              "appSpecificFiles": [],
              "applicationPort": 7001,
              "applicationMode": false,
              "logLocations": [],
              "enableDynamicLogging": false,
              "dependencies": []
       },

La sección NO EDITABLE incluye información de análisis a nivel de aplicación que app2container utilizará durante la contenerización, como datos del sistema operativo, puertos en uso, dependencias, bibliotecas de software, etc.

Extraer y Conteinerizar

Ahora lo siguiente en el proceso es extraer los artefactos de Weblogic y su aplicación desplegada ahí para la contenerización y generación de un Dockerfile.

Si revisamos la salida del comando analyze, podemos ver que el último de los siguientes pasos sugeridos por app2container, ya nos indica el comando para generar la extracción y la conteinerización. En este caso lo ejecutaremos del siguiente modo:

sudo app2container remote extract --target 10.10.10.10 --application-id java-generic-3828c90a9007

El proceso de extracción tomará unos minutos y app2Container creará un archivo zip que incluye todos los artefactos de la aplicación. Después de este punto, no necesita comunicarse con el servidor de aplicaciones Weblogic ya que app2container tiene ahora todos los artefactos relacionados con la aplicación en la máquina de trabajo.

Si todo fue bien en la extracción, debe ver un mensaje como el siguiente:

👍 Extraction successful for application java-generic-3828c90a9007

Una vez finalizada la extracción y que ya tenemos todos los artefactos necesarios en la máquina de trabajo, podemos indicar ahora a app2container que lo convierta a un contenedor de Docker. Para esto utilizaremos el comando containerize, como se muestra a continuación, en él debe proporcionar la ruta del archivo zip que se generó como salida del comando extract.

sudo app2container containerize --input-archive /root/app2container/remote/10.10.10.10/java-generic-3828c90a9007/java-generic-3828c90a9007-extraction.tar

El proceso tarda algunos minutos, y mostrará un mensaje de error como el siguiente:

⚠️
Pre-validation of your image failed.

Este mensaje se debe a que app2container generó un Dockerfile con un comando healthcheck genérico, basándose únicamente en el puerto 7001 detectado durante la fase de análisis.

Para remediar este asunto debemos modificar el comando healthcheck del Dockerfile, por lo que en este caso debemos editar el archivo “/root/app2container/java-generic-3828c90a9007/Artifacts/Dockerfile”.

La parte que nos interesa modificar es la que se encuentra al final del archivo, donde se especifica el comando healthcheck, lo cambiaremos por un recurso web que sabemos funciona en un servidor Weblogic, en este caso el valor correcto debe ser el siguiente:

HEALTHCHECK --interval=5s CMD wget --no-verbose --tries=1 --spider localhost:7001/console || exit 1

Una vez realizada la actualización del Dockerfile, realizamos de nuevo la contenerización desde app2container, usando de nuevo el comando containerize, pero esta vez de la siguiente forma:

sudo app2container containerize --application-id java-generic-3828c90a9007 --build-only

La salida de este último comando debe ser como lo siguiente:

✔ AWS prerequisite check succeeded
✔ Docker prerequisite check succeeded
✔ Using existing Dockerfile
✔ Generated deployment file at /root/app2container/java-generic-3828c90a9007/deployment.json
✔ Deployment artifacts generated.
✔ Pre-validation succeeded.
👍 Containerization successful. Generated docker image java-generic-3828c90a9007
💡 You're all set to test and deploy your container image.

En este momento ya tiene su aplicación dentro de una imagen de contenedor en su repositorio local en la máquina de trabajo, para comprobarlo ejecute el comando “docker images” y verifique que se encuentre listada una imagen de contenedor “java-generic-3828c90a9007“. En su caso deberá aparecer con el nombre del identificador asignado a su proceso detectado en la etapa de Inventory.

Crear Artefactos de Despliegue

Al ejecutar el comando “app2container containerize”, se crea automáticamente un archivo deployment.json. Este archivo incluye la configuración del despliegue de AWS. Para este ejercicio cambiaremos el modelo de despliegue por defecto para especificar una infraestructura de Kubernetes en EKS.

Abra el archivo “/root/app2container/java-generic-3828c90a9007/deployment.json” y modifique las siguientes partes:

Cambie a false la creación de artefactos en ECS que se encontraba por defecto:

"ecsParameters": {
              "createEcsArtifacts": false,

Cambie a true la creación de artefactos en EKS:

"eksParameters": {
              "createEksArtifacts": true,

Una vez realizadas las modificaciones anteriores, puede realizar la ejecución del comando que nos generará las plantillas de CloudFormation para la infraestructura de despliegue del contenedor.

sudo app2container generate app-deployment --application-id java-generic-3828c90a9007

La salida debe de ser similar a lo que se muestra a continuación:

✔ AWS prerequisite check succeeded
✔ Docker prerequisite check succeeded
✔ Processing application java-generic-3828c90a9007...
✔ Created ECR repository <account-id>.dkr.ecr.us-west-2.amazonaws.com/java-generic-3828c90a9007
✔ Pushed docker image <account-id>.dkr.ecr.us-west-2.amazonaws.com/java-generic-3828c90a9007:latest to ECR repository
✔ Generated CloudFormation Master template at: /root/app2container/java-generic-3828c90a9007/EksDeployment/amazon-eks-entrypoint-new-vpc.yaml
✔ Uploaded CloudFormation resources to S3 Bucket: app2container-weblogic-dec-10
👍 CloudFormation templates and additional deployment artifacts generated successfully for application java-generic-3828c90a9007
💡 You're all set to use AWS CloudFormation to manage your application stack.

Cuando usted ejecuta el comando generate app-deployment, App2Container valida las propiedades del archivo deployment.json y envía la imagen del contenedor a Amazon ECR. Este es el flujo de trabajo estándar.

El comando genera una plantilla de CloudFormation (amazon-eks-entrypoint-new-vpc.yml) que crea un clúster EKS, extrae las imágenes de contenedor de su aplicación de Amazon ECR y despliega su aplicación en el clúster.

También se han subido a su Bucket de S3 algunos manifiestos de Kubernetes (eks_deployment.yaml y eks_service.yaml), para las personalizaciones posteriores al despliegue mediante una herramienta como kubectl.

Desplegar en la nube de AWS

Ahora que tenemos las plantillas de CloudFormation listas para el despliegue del clúster de Kubernetes (EKS) que contendrá nuestra aplicación Java en Weblogic, solo queda hacer una adecuación a la capacidad de cómputo que estará utilizando dicho clúster, ya que de manera genérica app2container asigna un tipo de instancia y capacidad de almacenamiento, pero debemos ajustarlo a las necesidades de nuestra aplicación.

En este caso realizaremos primero un cambio al tipo de instancia, para ello es necesario que modifique el siguiente archivo: “/root/app2container/java-generic-3828c90a9007/EksDeployment/amazon-eks-entrypoint-new-vpc.yaml”

NodeInstanceType:
    Default: t3.large

Además, vamos a cambiar el tamaño de los volúmenes de almacenamiento. Esto se debe realizar modificando el archivo que desplegó app2container en su Bucket de S3: “s3://<S3Bucket>/<App-Id>/eks/submodules/quickstart-amazon-eks-nodegroup/templates/amazon-eks-nodegroup.template.yaml“. Guárdelo con la actualización en la parte que se muestra a continuación y cárguelo de nuevo en el bucket de S3.

NodeVolumeSize:
    Default: 300

Siéntase libre de realizar más cambios a la infraestructura dependiendo de las necesidades de su aplicación. En este caso únicamente realizaremos los anteriores.

El siguiente paso es ejecutar la plantilla de CloudFormation para generar la infraestructura de EKS en su cuenta de AWS. Para ello debe ejecutar el siguiente comando, cuidando como siempre de utilizar su propio application-id.

aws cloudformation deploy --template-file /root/app2container/java-generic-3828c90a9007/EksDeployment/amazon-eks-entrypoint-new-vpc.yaml --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND --stack-name a2c-java-generic-3828c90a9007-EKS

En este paso puede pasar a la consola de AWS y monitorear directamente el estado del despliegue de la infraestructura en la consola de CloudFormation.

Una vez finalizado el despliegue, puede pasar a la consola de EKS y validar que el nuevo clúster se encuentre activo:

 


Figura 3. Clúster generado en EKS

 

Los descriptores de Kubernetes generados por app2container, han creado un Ingress Controller para atender las peticiones externas hacia la consola de administración de Weblogic. Esto lo puede verificar en la consola de Elastic Load Balancer, donde encontrará un nuevo balanceador de carga.

  1. Abra la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
  2. En el panel de navegación, en LOAD BALANCING (balanceo de carga), elija Load Balancers (Balanceadores de carga).
  3. Seleccione el balanceador de carga más recientemente creado y, a continuación en el panel inferior, elija Description (Descripción), y en la sección de configuración básica, localice el campo DNS Name (Nombre de DNS).
  4. Copie el DNS Name de dicho servidor para acceder a su consola de Weblogic en Kubernetes usándolo de la siguiente forma en su navegador web: “DNSName/console“

Ahora debería poder acceder a su consola de administración de Weblogic, esta vez, ya desplegada en Kubernetes a través de EKS:

 


Figura 4. Weblogic desplegado en EKS

 

Con esto usted ha podido generar con éxito una imagen de contenedor de Docker de su aplicación desplegada en Oracle Weblogic, y la ha desplegado en un clúster de Kubernetes administrado por EKS en AWS.

 

Conclusión

Con AWS App2Container usted puede migrar aplicaciones hacia contenedores, incluyendo aplicaciones Java en servidores como Weblogic 12c. Hemos visto como App2Container analiza las aplicaciones y de forma automática genera una imagen de contenedor configurada con las dependencias, las configuraciones de red y las instrucciones de implementación para ECS o EKS correctas, permitiendo consolidar la infraestructura y las habilidades que se necesitan para operar las aplicaciones, lo que permite reducir los costos de la infraestructura y la capacitación.

Es importante mencionar que Oracle Weblogic tiene sus propias normas de licenciamiento, y que son ajenas a AWS, por lo que debe verificar siempre que antes de realizar un proceso de modernización como este, se encuentre en cumplimiento de dichas normas.

En términos de seguridad, usted tiene la capacidad de adecuar y personalizar todos los artefactos de despliegue que genera App2Container; puede cambiar el sistema operativo, las configuraciones de red de su clúster de Kubernetes, el tipo de balanceador, el modelo de almacenamiento, configurar el uso de canales cifrados, entre otras cosas. Recomendamos que analice estos artefactos y los adecúe según sus necesidades.

Esta ha sido una guía que le permitirá entender los principales pasos para modernizar una aplicación desplegada en Oracle Weblogic 12c. Usted puede tomarla como base y adaptarla para usarla como parte de sus arquitecturas de transición en la estrategia de modernización de sus aplicaciones.

 

Sobre el Autor

Christian Castro es Arquitecto de Soluciones Senior para Gobierno Federal de México en Sector Público, además forma parte de la comunidad técnica de contenedores (TFC) dentro de AWS.