https://www.businesswire.com/news/home/20210603005597/en/EVO-Announces-Acquisition-of-Pago-F%C3%A1cil-Gateway-in-Chile https://www.df.cl/noticias/mercados/banca-fintech/bci-pagos-anuncia-que-compra-la-fintech-chilena-pago-facil/2021-06-03/092751.html Hoy se ha marcado uno de los últimos hitos en el que participaré de manera activa en Pago Fácil; hoy es el día que mi emprendimiento fue adquirido por Evo Payments, una empresa de procesamiento de pagos internacional. Fueron un poco más de 3 años de esfuerzo y sacrificio que culminaron en esta … Leer más
Cuando creas una cuenta organizacional en Github y van pasando los años, la probabilidad de que muchas personas tanto internas como externas hayan pasado por tu empresa. Esto mismo pasa con los repositorios, muchos de ellos quedan huerfanos y ya no tiene sentido que existan debido a que su código tampoco está en uso.
Utilizando las APIs de GITHUB es muy sencillo filtrar los repositorios por la última actualización que tuvieron, lo que hace mucho más sencillo el proceso de archivar estos repositorios.
En este mini post mostraré una forma «sencilla» de facilitar la eliminación de los repositorios de tu organización de GitHub sin uso, sin embargo no automatizaremos esta eliminación.
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.
AWS CLI Instalado. Esto nos permitirá hacer el deployment de la aplicación de manera directa.
Tener una Red Privada con la cual queramos acceder al servicio (VPC)
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
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.
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.
👉 ¿Te gustó este contenido? Hay más esperando por ti.
Cada semana, comparto aprendizajes y reflexiones que no encontrarás en ningún otro lugar. ¡Únete a la comunidad de más de 9,000 emprendedores que ya están avanzando!
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.
Travis-CI es un sistema de Integración Continua, y es una herramienta muy importante en el mundo de la automatización de pasos a producción, mientras que GitHub Package Repository corresponde a un sistema de manejo de paquetes y dependencias relativamente nuevo proporcionado por GitHub.
Estamos modificando el flujo de automatización que tenemos de paso a producción, y un amigo me recomendó enormemente ( y reiteradamente ) que comenzara a usar TravisCI.
Hace bastante no escribía un blogpost, sin embargo pasé un par de horas que no tenía planeadas en invertir en esta conexión así que creo que amerita escribir algo al respecto.
Antes de iniciar :
Debes de tener una cuenta en GitHub
Debes de tener una cuenta en TravisCI
Asumiré que la conexión entre ambos ya está realizada y tienes un proyecto que incluya un paquete alojado en GITHub Package Repository.
Emprendedor, inversionista, y mentor de diversas Startups y Emprendimientos.
Apasionado de la tecnología, los negocios y la educación. Tanto personal como profesionalmente mi idea es estar siempre buscando la excelencia, sacar lo mejor de mis capacidades, todos los días se puede aprender algo más y estaré feliz de hacerlo.
Mi propósito es ayudar a los emprendedores, lograr que salgan adelante, y potenciar el ecosistema Startup.