API Privada con Serverless Framework, AWS y VPCs.

Api Gateway Private Endpoint

Generalmente cuando hablamos de APIs pensamos en la forma como otros desarrolladores se pueden conectar a nuestros sistemas, productos, o servicios. Sin embargo, cuando empiezas a desacoplar tus sistemas te das cuenta que el utilizar APIs para el desarrollo interno puede ser igual o más útil para el negocio.

Este ejemplo sencillo muestra como poder crear un API privada usando Serverless Framework y Amazon Web Services. Ojo, pestaña, y ceja, lo que estoy haciendo con este ejemplo no es hacer privada un API a través de autentificación y autorización, eso siempre se puede agregar sobre el API como una capa de seguridad aún mayor, en este caso estamos haciendo privada la conexión para que solo pueda ser accedida desde nuestra VPC a través de un AWS PrivateLink.

Ya han pasado un poco más de dos años desde que AWS lanzó esta  funcionalidad, sin embargo no había tenido la oportunidad y necesidad de utilizarla anteriormente. Pueden leer el Post original de AWS acá : https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/

El código de este ejemplo puede ser encontrado en GitHub : https://github.com/ctala/serverless-private-api-endpoint

Requerimientos

  1. Cuenta en AWS.
  2. Serverless Framework Instalado
  3. AWS CLI Instalado. Esto nos permitirá hacer el deployment de la aplicación de manera directa.
  4. Tener una Red Privada con la cual queramos acceder al servicio (VPC)
  5. Tener una máquina a la que podamos acceder para poder probar el servicio.

Creando el VPC Endpoint

Para generar el endpoint a utilizar, nos dirigimos al menú de VPCs de la consola de AWS, seleccionamos el sub-menú de endpoints en el costado izquierdo, y luego crear uno nuevo. Nos debería aparecer algo como lo que se muestra a continuación.

VPC Endpoint
VPC Endpoint

Si en busqueda escribimos execute-api, nos debería aparecer por defecto la opción que necesitamos para que este endpoint pueda ejecutar la API que crearemos. A continuación seleccionamos el VPC, las subnets, y las security groups correspondientes y damos click en continuar.

El Id de Endpoint resultante lo usaremos en nuestra configuración del Serverless.

Resource Policy

Antes de configurar el serverless, debemos definir quién puede y/o no puede tener acceso a nuestra red privada. En este caso, copiaremos el resource policy de ejemplo de AWS que hace Whitelist de la VPC que puede ejecutarlo (Se puede encontrar bajo Resources Policies en el menú de cualquier API bajo API Gateway.). La idea es que generemos este mismo Resource Policy usando la configuración del Serverless Framework.

Código del Serverless

El siguiente código es el que genera el Resource Policy mostrado anteriormente y levanta un Lamda con su API Gateway respectivo con un endpoint privado, además del endpoint por defecto del Serverless Framework con Hello World.

service: sls-test-private-endpoint
frameworkVersion: '2'

provider:
name: aws
runtime: nodejs12.x
region: us-west-2
stage: dev
endpointType: PRIVATE
vpcEndpointIds:
- vpce-0631ee46a323b75e4

#El Resource Policy que generamos primero bloqueará todo el tráfico que no sea de la/las VPCs listadas a bajo aws:sourceVpc, luego permitimos
# el acceso de todo lo demás.
resourcePolicy:
##Bloqueo de lo que no corresponde al VPC
- Effect: Deny
Principal: "*"
Action: execute-api:Invoke
Resource:
- execute-api:/*/*/*
Condition:
StringNotEquals:
aws:sourceVpc:
- vpc-03602a6783bdefb87
##Permiso a lo demás. Acá también podemos bloquiar por segmento de IP.
- Effect: Allow
Principal: "*"
Action: execute-api:Invoke
Resource:
- execute-api:/*/*/*

functions:
hello:
handler: handler.hello
events:
- http:
path: /
method: get

 

Probando la conexión.

 

Acá queremos hacer dos cosas, la primera es revisar que no podamos acceder a la URL desde nuestros computadores. Ya que el endpoint es un GET simplemente probamos utilizando la URL resultante del deployment, por ejemplo : https://80nyvq2u70.execute-api.us-west-2.amazonaws.com/dev/ . Si bien la URL mostrada es la original, no puede ser accedida debido a que está dentro de una API privada.

Para probar realmente que podemos acceder a esta API desde la VPC, lo que tenemos que hacer es llamarla desde una máquina que esté en esta. En este caso un simple comando Curl nos puede ayudar desde la consola de la máquina virtual.

curl -v https://80nyvq2u70.execute-api.us-west-2.amazonaws.com/dev/

En este caso, si todo salió según lo esperado, obtendremos la respuesta del serverless incluyendo todos los headers agregados desde AWS.

curl -v https://80nyvq2u70.execute-api.us-west-2.amazonaws.com/dev/
* Trying 10.0.16.153:443...
* TCP_NODELAY set
* Connected to 80nyvq2u70.execute-api.us-west-2.amazonaws.com (10.0.16.153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.execute-api.us-west-2.amazonaws.com
* start date: Apr 29 00:00:00 2020 GMT
* expire date: Apr 13 12:00:00 2021 GMT
* subjectAltName: host "80nyvq2u70.execute-api.us-west-2.amazonaws.com" matched cert's "*.execute-api.us-west-2.amazonaws.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
> GET /dev/ HTTP/1.1
> Host: 80nyvq2u70.execute-api.us-west-2.amazonaws.com
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Server
< Date: Wed, 23 Sep 2020 23:13:15 GMT
< Content-Type: application/json
< Content-Length: 2402
< Connection: keep-alive
< x-amzn-RequestId: e247cbde-523a-4867-89be-9588d3654b70
< x-amz-apigw-id: TV51yHB-PHcF2Mg=
< X-Amzn-Trace-Id: Root=1-5f6bd68b-2ef4b5a7424ef64695dd27cd;Sampled=0
< 
{
"message": "Go Serverless v1.0! Your function executed successfully!",
"input": {
"resource": "/",
"path": "/",
"httpMethod": "GET",
"headers": {
"Accept": "*/*",
"Host": "80nyvq2u70.execute-api.us-west-2.amazonaws.com",
"User-Agent": "curl/7.68.0",
"x-amzn-cipher-suite": "ECDHE-RSA-AES128-GCM-SHA256",
"x-amzn-tls-version": "TLSv1.2",
"x-amzn-vpc-id": "vpc-03602a6783bdefb87",
"x-amzn-vpce-config": "1",
"x-amzn-vpce-id": "vpce-0631ee46a323b75e4",
"X-Forwarded-For": "10.0.3.28"
},
"multiValueHeaders": {
"Accept": [
"*/*"
],
"Host": [
"80nyvq2u70.execute-api.us-west-2.amazonaws.com"
],
"User-Agent": [
"curl/7.68.0"
],
"x-amzn-cipher-suite": [
"ECDHE-RSA-AES128-GCM-SHA256"
],
"x-amzn-tls-version": [
"TLSv1.2"
],
"x-amzn-vpc-id": [
"vpc-03602a6783bdefb87"
],
"x-amzn-vpce-config": [
"1"
],
"x-amzn-vpce-id": [
"vpce-0631ee46a323b75e4"
],
"X-Forwarded-For": [
"10.0.3.28"
]
},
"queryStringParameters": null,
"multiValueQueryStringParameters": null,
"pathParameters": null,
"stageVariables": null,
"requestContext": {
"resourceId": "2qf3us2l93",
"resourcePath": "/",
"httpMethod": "GET",
"extendedRequestId": "TV51yHB-PHcF2Mg=",
"requestTime": "23/Sep/2020:23:13:15 +0000",
"path": "/dev/",
"accountId": "607613765343",
"protocol": "HTTP/1.1",
"stage": "dev",
"domainPrefix": "80nyvq2u70",
"requestTimeEpoch": 1600902795396,
"requestId": "e247cbde-523a-4867-89be-9588d3654b70",
"identity": {
"cognitoIdentityPoolId": null,
"cognitoIdentityId": null,
"vpceId": "vpce-0631ee46a323b75e4",
"principalOrgId": null,
"cognitoAuthenticationType": null,
"userArn": null,
"userAgent": "curl/7.68.0",
"accountId": null,
"caller": null,
"sourceIp": "10.0.3.28",
"accessKey": null,
"vpcId": "vpc-03602a6783bdefb87",
"cognitoAuthenticationProvider": null,
"user": null
},
"domainName": "80nyvq2u70.execute-api.us-west-2.amazonaws.com",
"apiId": "80nyvq2u70"
},
"body": null,
"isBase64Encoded": false
}
* Connection #0 to host 80nyvq2u70.execute-api.us-west-2.amazonaws.com left intact
}

Y eso sería todo. Con estos pasos sencillos podemos tener nuestra API privada funcionando para ser accedida desde los recursos que estén dentro de nuestra VPC.

¡Mantengamos el contacto!

Me encantaría que te mantuvieras al día con el contenido que estoy generando. Recuerda que no es solo el blog, son las redes sociales, libros, y distintos pódcast 😎.

Hago todo lo posible para no hacer Spam,

¡MANTENGÁMONOS EN CONTACTO!

Me encantaría que te mantuvieras al día con el contenido que estoy generando. Recuerda que no es solo el blog, son las redes sociales, libros, y distintos pódcast 😎.

Hago todo lo posible para no hacer Spam,

Tutorial : Full RESTfull API con AWS, Terraform, y Serverless Framework

Hace ya algunos años que he querido hacer un tutorial como este, en dónde de manera sencilla pueda explicar los distintos pasos de la creación de un API REST, o al menos como lo he aprendido a hacer basado en experiencia y errores.

Una de las razones del por qué nunca comencé con este proyecto es debido a que crear un API puede ser tan complejo como uno quiera, y nunca encontré el tiempo para realizarlo, por lo que decidí lanzar este tutorial por partes e iré publicando las distintas partes a medida que las vaya realizando.

En este tutorial crearemos un Full RESTfull API con seguridad basada en tokens utilizando AWS, Swagger, Terraform, DynamoDB, SSM, y Serverless Framework quién generará los recursos del API Gateway y Lambdas.

 

Estado Proyecto En Progreso
Fecha Inicio 17/05/2020
Fecha Actualización 17/05/2020
Fecha de Término
Capítulos listos 2/10
Link Youtube Playlist https://www.youtube.com/playlist?list=PLCjIDwuXOgwR64ScpUf6WLnW6j2jdkREX

 

Indice

  1. Entendiedo la necesidad. API de manejo de datos de usuarios y los datos requeridos.
  2. Conociendo las herramientas que se utilizarán y el por qué las usaremos.
  3. Diseñando la API utilizando Swagger. Antes de crear el API debemos saber que información recibirá y que información retornará.
  4. Generando la base de datos DynamoDB, y el recurso relacionado de SSM utilizando Terraform.
  5. Generando los endpoints utilizando Serverless Framework.
  6. Generando el CRUD de la aplicación. – Create, Read, Update, Delete –
  7. Asegurando nuestra API.

Extra

  1. Bloqueo de recursos en Terraform para impedir eliminaciones accidentales.
  2. Endpoint que lista los usuarios con paginación.
  3. Sincronizando DynamoDB con Redshift para realizar operaciones analiticas.

Read more

Jugando con el #PHP SDK de Amazon Web Services ( #AWS ) V3 para Simple Queue Service (#SQS)

Amazon SQS Ejemplo PHP SDK V3

Simple introducción a Amazon Simple Queue Service usando Composer, PHP y la versión 3 del SDK de Amazon.  Amazon SQS es un servicio de mensajería para la comunicación entre distintas plataformas y/o dispositivos.

Origen: Basic SDK Usage

Código del Proyecto : Jugando con PHP SDK y SQS

Hace un tiempo que quería empezar a usar SQS para separar la lógica de envío de correos de mi plataforma, en especial desde que tuve problemas en su momento con el servidor SMTP de Mandrill lo que finalizaba en un error para el usuario. En este momento cambie a usar el sistema de mails de Amazon, pero siempre quedé con la intención de separar el procesamiento de emails en caso de tener problemas con esto nuevamente.

Me llamó mucho la atención que los ejemplos de Amazon para el SDK simplemente están basados en S3, por l oque no fue tan sencillo comenzar con SQS como lo hubiera imaginado, casi todos los ejemplos con SQS usaban las librerías antiguas.

Amazon SQS, no solo sirve para poder enviar emails de manera asyncrónica con la aplicación, la verdad es que puedes hacer lo que se te ocurra. Por ahora empezaremos un proyecto desde cero en el cual crearemos mensajes y luego los procesaremos.

Amazon SQS Ejemplo PHP SDK V3
Amazon SQS Ejemplo PHP SDK V3

Inicializando El Proyecto de SQS.

Lo primero que necesitamos es instalar las librerías del SDK, por lo crearemos una nueva carpeta y utilizaremos composer para instalarlas. Si no sabes lo que es composer te recomiendo que vayas a su sitio web para instalarlo : https://getcomposer.org/

composer require aws/aws-sdk-php

 

Con esto crearemos la estructura básica para continuar, en donde las librerías necesarias se descargarán en la nueva carpeta vendor.

Ahora crearemos 3 archivos en la raiz del directorio :

  • sharedConfig.php que tendrá los datos de conexión y valores por defecto.
  • createMessage.php que creará la Queue si es que no existe y agregará un nuevo mensaje.
  • readMessages.php que leerá todos los mensajes que tenemos en el Queue, los procesará y luego los eliminará.

sharedConfig.php

// Usaremos esta información por defecto.
$sharedConfig = [
 'region' => 'us-west-2',
 'version' => 'latest',
 'credentials' => [
 'key' => 'TUKEY',
 'secret' => 'TUSECRET',
 ],
];

$my_queue_name = "MyQueueExample";

La verdad no es recomendable hardcodiar los datos de conexión, pero como ejemplo está perfecto. Recomiendo usar las variables de entorno para los datos de conexión.

Creando Los Mensajes de SQS

El siguiente código crea la instancia del SDK, y desde ella obtenemos el cliente para SQS, creamos el queue y agregamos un mensaje. Si el nombre del Queue existe hace nada. Si bajaste el código desde el repositorio recuerda crear el archivo sharedConfig.php como aparece en la sección anterior.

Es bueno destacar que cualquier llamada del cliente a amazon puede tener un error que debemos capturar en caso de ser necesario.

createMessage.php

require 'vendor/autoload.php';
include_once 'sharedConfig.php';

// Creamos la clase SDK.
$sdk = new Aws\Sdk($sharedConfig);

// Creamos el cliente SQS desde el SDK
$client = $sdk->createSqs();

// Creamos la QUEUE
$queue_options = array(
 'QueueName' => $my_queue_name
);

try {
 $client->createQueue($queue_options);
} catch (Exception $exc) {
 echo $exc->getTraceAsString();
 die('Error creando la queue ' . $exc->getMessage());
}


// Obtenemos la URL de la queue.
$result = $client->getQueueUrl(array('QueueName' => $my_queue_name));
$queue_url = $result->get('QueueUrl');

print_r($queue_url);

// The message we will be sending
$our_message = array(
 'tipo' => 'MAIL',
 'content' => rand(0, 110000010)
);

// Send the message

try {
 $client->sendMessage(array(
 'QueueUrl' => $queue_url,
 'MessageBody' => json_encode($our_message)
 ));
} catch (Exception $ex) {
 die('Error enviando el mensaje a la queue ' . $e->getMessage());
}

 

  1. Se cargan las librerías de composer. En este caso solo tenemos las de Amazon SDK
  2. Incluímos el archivo de configuración con las KEY. Recuerda que debes de cear este archivo.
  3. Creamos la instancia del SDK.
  4. Creamos el cliente de SQS.
  5. Creamos las opciones para la creación del Queue.
  6. Creamos el Queue. Recueda que si ya existe no hará nada.
  7. Obtenemos e imprimos en pantalla la url de la Queue.
  8. Creamos el mensaje a agregar a la cola. En este caso nuestro mensaje es un arreglo, por eso usaremos json_enconde al momento de enviar el contenido.
  9. Enviamos el contenido del mensaje.

En este caso solo estamos enviando un mensaje. Sin embargo puedes ejecutar el código cuantas veces quieras. Ejecutando por consola sería :

$ php createMessage.php

 

 

Leyendo, Procesando Y Eliminando Los Mensajes de SQS

Ahora a la parte entretenida. En este caso, solo por preferencia, el código se ejecutará por siempre y para no tener el CPU al 100% si es que no existen mensajes pendientes esperaremos un tiempo definido por la variable backoff. Esto lo aprendí cuando hice experimentación con redes inalambricas :).

Con cada iteración se obtendrá un solo mensaje en caso de existir. Si el mensaje no es eliminado, volverá a estar en la cola luego de un tiempo.

readMessages.php

require 'vendor/autoload.php';
include_once 'sharedConfig.php';

// Creamos la clase SDK.
$sdk = new Aws\Sdk($sharedConfig);

// Creamos el cliente SQS desde el SDK
$client = $sdk->createSqs();

// Obtenemos la URL de la queue.
$result = $client->getQueueUrl(array('QueueName' => $my_queue_name));
$queue_url = $result->get('QueueUrl');

/*
 * Si no hay un mensaje en el Queue 
 * esperaremos un tiempo
 * definido por backoff y delimitado por 
 * $backoffMax
 */

$backoff = 0;
$backoffMax = 3;
while (true) {

try {
 $message = $client->receiveMessage(array(
 'QueueUrl' => $queue_url
 ));
 } catch (Exception $exc) {
 echo "No se pudo obtener mensaje \n";
 echo $exc->getTraceAsString();
 }

if ($message['Messages'] == null) {
 // No hay mensajes a procesar.
 echo "No hay mensajes a procesar. Duermo.\n";
 $backoff += 0.5;
 if ($backoff > $backoffMax) {
 $backoff = $backoffMax;
 }
 echo "Espero $backoff segundos";
 sleep($backoff);
 } else {
 $backoff = 0;
 echo "Hay mensajes a procesar. Proceso.\n";
 // Obtengo la información del mensaje

$result_message = array_pop($message['Messages']);
 $queue_handle = $result_message['ReceiptHandle'];
 $message_json = $result_message['Body'];

//Imprimimos el contenido del mensaje
 print_r($message_json);

echo "\n";
 //Ahora eliminamos.

try {
 $client->deleteMessage(array(
 'QueueUrl' => $queue_url,
 'ReceiptHandle' => $queue_handle
 ));
 echo "\t Mensaje eliminado\n";
 } catch (Exception $exc) {
 echo $exc->getTraceAsString();
 echo "\t Mensaje NO eliminado\n";
 }
 }
}

Ignoraré la explicación de lo que se explicó anteriormente.

  1. La variable backoff corresponde al tiempo de espera para ver si existen nuevos mensajes.
  2. La variable backoffMax corresponde al tiempo máximo de espera.
  3. result_message corresponde al mensaje que desencolamos del Queue.
  4. queue_handler corresponde a la variable a utilizar en caso de que queramos borrar el mensaje.
  5. $message_json corresponde al mensaje en formato json. Recuerda que lo encondificamos al enviarlo.
  6. la funciona deleteMessage hace exactamente eso, elimina el mensaje del Queue.

¿ Y ahora ?

Eres bienvenido a ejecutar el código que está en el repositorio, solo recuerda crear el archivo sharedConfig.php con tus datos de Amazon : https://github.com/ctala/Jugando-con-PHP-SDK-y-SQS

¡Mantengamos el contacto!

Me encantaría que te mantuvieras al día con el contenido que estoy generando. Recuerda que no es solo el blog, son las redes sociales, libros, y distintos pódcast 😎.

Hago todo lo posible para no hacer Spam,

¡MANTENGÁMONOS EN CONTACTO!

Me encantaría que te mantuvieras al día con el contenido que estoy generando. Recuerda que no es solo el blog, son las redes sociales, libros, y distintos pódcast 😎.

Hago todo lo posible para no hacer Spam,

Desarrollando Aplicaciones Web con PHP7.0 y Docker

Docker es un software de manejo de contenedores, mientras que PHP7.0 es la última versión de este lenguaje de programación que incluye mejoras que hacen que la velocidad de su funcionamiento sea 50% más veloz que su predecesor. En este tutorial crearemos un ambiente de desarrollo usando Docker con lo cual no tendremos que instalar ningún otro software ni librería para funcionar.

Origen: ctala/apache2_php7_awsebs – Docker Hub

Docker

Ya hace un tiempo que quería probar como funcionaba Docker para el desarrollo de aplicaciones para no tener que instalar todo nuevamente en mi máquina. Hace unos días ya llegó mi nueva laptop por lo que ya no tengo excusas para no trabajar y se me ocurrió la brillante idea de procastinar aprendiendo y creando imagenes de Docker en vez de iniciar directamente con lo que debía hacer. El resultado fue satisfactorio por lo que estoy muy contento, así que aprovecho de compartir no solo como desarrollar en PHP7.0 usando Docker, si no que además utilizaremos una imagen que creé para este cometido que incluye todo lo necesario para poder desarrollar sin problemas en PHP7.0, además de herramientas que hacen que el proceso sea más sencillo.

Prerequisitos :

  • Tener Docker ya instalado.
  • Los comandos que mostraré son en base a un HOST linux, lo que no quiere decir que la imagen que ocuparemos no funcione con otro HOST.

Obteniendo la Imagen

Uno de los beneficios de trabajar con containers, es que podemos instalar uno de ellos en base a una imagen que ya tenga todo para llegar y utilizar. Uno de los problemas que tuve al inicio es que no entendí muy bien cual era la diferencia entre un contenedor y una imagen, lo que podemos resumir como que el contenedor es la visualización de la imagen que ocuparemos. ” El contenedor es el que ocuparemos, mientras que la imagen genera el contenedor “.

Ejecutamos el siguiente comando para descargar la imagen que utilizaremos como base para el contenedor que tendrá nuestra aplicación web.

docker pull ctala/apache2_php7_awsebs

 

Con el comando anterior descargamos la imagen base. No importa cuantos contenedores creemos en base de esta imagen, esta imagen solo deberemos descargarla una vez.

Iniciando el contenedor.

La imagen anterior esta lista para ser utilizada y al momento de [generar el contenedor inicia el servidor web Apache de manera automática. En este caso solo debemos enfocarnos en iniciar el contenedor. Algo que vale la pena destacar es que si el contenedor es eliminado, todo el contenido se pierde. Debido a esto se montará la carpeta donde tenemos el código web desde la máquina HOST para no tener problemas.

sudo docker run -d -p 80:80 -i \
-v/MIREPO:/var/www/html \
-t ctala/apache2_php7_awsebs

 

El comando anterior ejecuta el contenedor como demonio por lo que no se eliminará si salimos, hace un puente entre el puerto 80 del contenedor y el puerto 80 de nuestro host ( Computador ) y monta la carpeta /MIREPO que tiene el repositorio local en la dirección web del servidor desde nuestra imagen llamada apache2_php7_awsebs.

Accediendo al contenedor.

Uno de los beneficios de Docker es que podemos acceder al contenedor como si fuera una máquina virtual. Para hacerlo simplemente listamos los contenedores que estén corriendo y “ejecutamos” una consola bash para poder acceder.

sudo docker ps
Contenedores Docker Activos
Contenedores Docker Activos

El comando anterior resulta en la lista de los contenedores activos con su respectivo ID y los puertos que está ocupando. En nuestro caso el puerto 80 del contenedor está relacionado con el puerto 80 de nuestra máquina host.

Ahora asumiendo que tenemos el resultado anterior, ingresaremos a la consola de esa máquina.

$ sudo docker exec -it 78764af8e071 bash

 

Con esto podemos instalar todo lo que nos haya faltado, utilizar las herramientas incluidas, o simplemente analizar los logs del sistema.

 

Otras Herramientas Incluidas.

Esta imagen no solo viene con PHP7.0 y Apache, también viene lista con :

  • Cliente Mysql.
  • Composer, para el manejo de las librerías de PHP.
  • EBS-CLI. Herramientas para la conexión con Elastic BeanStalk de Amazon.
  • Curl.
  • Git para el manejo de los repositorios.

Usando esta imagen puedes crear tantos contenedores como lo deseos o simplemente usar uno y cambiar la dirección desde donde se obtiene la información del repositorio.

Por mi parte estaré utilizando está imagen para el desarrollo de aplicaciones por lo que estaré modificándola a medida que sea necesario.

¡Mantengamos el contacto!

Me encantaría que te mantuvieras al día con el contenido que estoy generando. Recuerda que no es solo el blog, son las redes sociales, libros, y distintos pódcast 😎.

Hago todo lo posible para no hacer Spam,

¡MANTENGÁMONOS EN CONTACTO!

Me encantaría que te mantuvieras al día con el contenido que estoy generando. Recuerda que no es solo el blog, son las redes sociales, libros, y distintos pódcast 😎.

Hago todo lo posible para no hacer Spam,

Actualizar Elastic BeanStalk Enviroment para usar PHP7.0 con eb-cli

AWS Elastic Beanstalk es un servicio fácil de utilizar para implementar y escalar servicios y aplicaciones web.

Ahora veremos como hacer el upgrade de la versión de PHP de un servicio ( enviroment ) ya corriendo.

Antes de hacerlo :

  1. Ya debes de estar familiarizado con lo que es ElasticBeanstalk.
  2. Debes de tener los comandos de consola de EB instalasdos ( EB-CLI ).
  3. Asumiremos el upgrade desde una máquina con consola linux.

Read more

Share to...