Portable Applications - Containers on AWS - …...Portable Applications - Containers on AWS October 2018 David Sanz, Solutions Architect, Amazon Web Services Fernando García, Product

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Portable Applications - Containers on AWSOctober 2018

David Sanz, Solutions Architect, Amazon Web Services

Fernando García, Product Lead @ BBVA Labs

Raimundo Alegría, Software Architect @ BBVA Labs

@awscloud_es


We all love containers


Everything is lovely around containers

Atomic

self-containedPortableLightweight

Containers and microservices go hand in hand


Running a container is super easy

$ docker run mykillerapp:0.0.1


Yes, we all love containers


Then it comes reality…

Server

Guest OS

Bins/Libs Bins/Libs

App1 App2


Then it comes reality…


… scale…


… and container orchestration

How do I deploy my containers to hosts?

• Zero downtime, blue green deployments

How do I keep my containers alive?

• Scheduling, recovery

How can my containers talk to each other?

• Service linking, discovery

How can I configure my containers at runtime?

• What about secrets

How do I best optimise my "pool of compute”?

• Placement, autoscaling


AWS, build a Docker service for us


Elastic Container Service launch at re:Invent 2014


Amazon Elastic Container Registry


Simplify how to run container-based apps in production

AWS VPC

networking mode

Global footprint

Advanced task

placement

Deep integration

with AWS platform

…{ } ECS CLI

Powerful scheduling

engines

Auto scaling

CloudWatch metrics

Load balancers


ECS as of December 2017

Over 100.000 clusters

Millions of instances

Hundreds of millions of new containers launched

each week


Fine, but what have you been up to lately?


Container access to environmental

metadata

Network Load Balancer

support

Console support for SpotFleet

Override parameters for RunTask

and StartTask APIs

Task Elastic Network Interface

Application Load

Balancer Support

HIPAA

eligibility

Console UX improvements

CLI V1.0

Container

instance draining

Windows containers

Cron and Cloudwatch

Event Task scheduling

Support for Docker

Privileged Mode

Lifecycle Policies for

container images

Beijing

Region

Support for

Device and Init

flags

Add attributes during boot

Seoul Region

Linux capabilities

ECS Service Team has been busy…


Same level of compliance as EC2

Global Quality

Standard

Security Mgmt

Controls

Cloud Specific

Controls

Personal Data

Protection

Audit Controls

Report

Security, Availability, &

Confidentiality Report

General Controls

Report

Payment Card Standards

PCI DSS Level 1

Protected Health

Information


Task VPC networking mode

Default/Root Global Namespace

docker0

Io

eth0

172.16.0.0

172.16.1.0

172.16.2.0

1. Pre ENI Attachment: The Primary

ENI (eth0) is in the default

namespace


docker0

Io

eth0

172.16.0.0

172.16.1.0

172.16.2.0eth1

2. ENI Attachment: The new

ENI (eth1) is in the default

namespace


ecs0

Io

eth0

172.16.0.0

172.16.1.0

172.16.2.0

do

cke

r0

Io

eth0

172.16.0.0

172.16.1.0

172.16.2.0

ve-c1

3. ENI Provisioned: The ECS Agent

invokes open source CNI plugins to

move the new ENI into the taks

namespace


Managed service discovery for ECS

Build apps where services are invoked by name

Name resolves to IP/port automatically

No infrastructure to manage

Route53 provides service registry


Full CI/CD with AWS CodePipeline

AWS

CodeCommit

AWS

CodeBuild

Amazon ECR Amazon ECS

Source

RepositoryBuild Deploy

or or

AWS

CodePipeline

Store Image


Windows containers

AWS VPC

networking mode

Global footprint

Advanced task

placement

Deep integration

with AWS platform

…{ } ECS CLI

Powerful scheduling

engines

Auto scaling

CloudWatch metrics

Load balancers


Ok, but I still have to manage the underlying cluster


Introducing Fargate

Launch tasks

Scale easily

No cluster

management

Resource based

pricing

No placement

No scheduling

Create a task definition (pod), set some resource characterization, and launch it


Fargate is just a launch mode

AWS VPC

networking mode

Global footprint

Advanced task

placement

Deep integration

with AWS platform

…{ } ECS CLI

Powerful scheduling

engines

Auto scaling

CloudWatch metrics

Load balancers


When to use Fargate vs EC2 launch mode

Fargate when:

You are OK with awsvpc networking mode

You want to pay only when pods/tasks run

EC2 when:

You need to customize the underlying images

You need to access the underlying instances

You want a network mode other than awsvpc

You want to take advantage of things like spot fleets


What I really love is Kubernetes


Vibrant and growing community

of Kubernetes workloads run

on AWS today

CNCF survey


AWS, would you build a Kubernetes service for us?


Introducing Elastic Container Service for Kubernetes


Amazon EKS is certified Kubernetes conformant

The Certified Kubernetes Conformance Program guarantees you can use all existing plugins and tooling from the Kubernetes community

Any application running on any standard Kubernetes environment is fully compatible


Availability

Zone 1

Etcd

Master

Etcd

Master

Availability

Zone 2

Availability

Zone 3

Etcd

Master

Amazon EKS architecture


Availability

Zone 1

Etcd

Master

Etcd

Master

Availability

Zone 2

Availability

Zone 3

Etcd

Master


Customer Account

AWS Managed


mycluster.eks.amazonaws.com

EKS Workers

kubectl


AZ 1 AZ 2 AZ 3

Your AWS account


Kubernetes upgrades

Major Minor Patch

Breaking

Changes

New

Features

Bug fixes

Security


Kubernetes / AWS Integrations


I want to give a pod permissions to an AWS service: kube2iam

• Runs as a DaemonSet on your workers

• Creates iptables rules to redirect metadata service to kube2iam

• Add annotations to your pods to grant them AWS IAM Roles


kube2iam example

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: nginx-deployment

spec:

replicas: 3

template:

metadata:

annotations:

iam.amazonaws.com/role: arn:aws:iam:123567989012/role/nginx-role

spec:

containers:

- name: nginx

image: nginx:1.9.1

ports:

- containerPort: 80


I want to use AWS accounts to operate Kubernetes: Heptio Authenticator for AWS

An open source approach to integrating

AWS IAM authentication with Kubernetes


kubectl

3) Authorizes AWS Identity with RBAC

K8s API

1) Passes AWS Identity

2) Verifies AWS Identity

4) K8s action

allowed/denied

AWS Auth

Heptio IAM authentication with kubectl


Amazon Elastic Container Registry


Native VPC networking

with CNI plugin

Pods have the same VPC

address inside the pod

as on the VPC

Simple, secure networkingOpen source and

on Github

https://github.com/aws/amazon-vpc-cni-k8s

I want my pods to have an ENI on my VPC: amazon-vpc-cni-k8s


Nginx Pod

Java Pod

ENI

Secondary IPs:

10.0.0.1

10.0.0.2

Veth IP: 10.0.0.1

Veth IP: 10.0.0.2

Nginx Pod

Java Pod

ENI

Veth IP: 10.0.0.20

Veth IP: 10.0.0.22

Secondary IPs:

10.0.0.20

10.0.0.22

ec2.associateaddress()

VPC Subnet – 10.0.0.0/24

Instance 1 Instance 2

CNI

CNI

Amazon VPC network mode


I want my services to be exposed through an AWS Load Balancer

$ kubectl run nginx --image=nginx --replicas 3 --port=80

$ kubectl expose deployment nginx --type=LoadBalancer

$ kubectl get services -o=wide

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)

nginx LoadBalancer 100.70.217.164 a5cefe533ac1d11e7a38f0a67818e472-1987464052.eu-west-1.elb.amazonaws.com 80:31108/TCP


Managed Kubernetes on AWS

Highly available Automated

version

upgrades

Integration

with other AWS

services

Etcd

Master

Managed

Kubernetes

control plane

CloudTrail,

CloudWatch, ELB, IAM,

VPC, PrivateLink


So, what are my choices to run a managed container platform on AWS?


Choose your

orchestration tool1

Choose your

launch type2

ECS EKS

EC2 Fargate EC2 Fargate

AWS Managed Container Services

Diseñando Sistemas Críticos en CloudAWS Transformation Day

Octubre 2018

BBVAInnovation

Labs

Fernando García, Product Lead

Raimundo Alegría, Software Architect

Diseñando un sistema crítico en Cloud / 52

¿Qué consideramos sistemas críticos?

Index

01

02

03

Principios de diseño para la evolución

Cloud

Conclusiones


¿Qué consideramos sistemas

críticos?


¿Qué consideramos un

sistema crítico?

Ofrece servicio a clientes

finales

Genera impacto económico

directo en la compañía

24x7 con disponibilidad de

“cuatro nueves”: 99,99%


¿Por qué evolucionar

sistemas críticos?

Adaptación a hábitos de

consumo cambiantes

Generar nuevos modelos de

negocio

Mercado mucho más

complejo y competitivo


This slide can be used to explain

a photo. Body text must be Open

Sans format, 15pt minimum size

and 18pt. maximum size is

recommended. Highlights Open

Sans Bold, sapien non iaculis.

¿Cuál es la situación

actual?

Sistemas monolíticos con

escalado vertical

Coste de cambio elevado y lento

Dificultad para encontrar perfiles

especializados


Principios de diseño para

evolucionar a una arquitectura

Cloud


Convivencia con el sistema actual: Evitar grandes big bangs, adoptando conceptos de

Arquitectura Evolutiva*

Adaptarse a los nuevos riesgos de seguridad y normativos derivados del uso de la nube

pública

Mejorar los requisitos no funcionales del sistema de partida: SLAs, observabilidad, auditoría,

escalado...

...antes de abordar la evolución, hay que entender las restricciones del entorno

Punto de partida. Premisas de diseño

(*) https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture


Microservicios**. Permiten

implementar arquitecturas

evolutivas

Maximizar el uso de la

plataforma para enfocarte en tu

negocio

“Container is the new .exe”. Todo

se ejecuta en containers

Ley de Conway*. Diseñar la

arquitectura como reflejo de la

estructura organizativa

Despliegue multiplataforma.

Minimizando el vendor-lock

Automatiza todo. Es imposible operar

un sistema complejo sin automatizar

todos sus aspectos.

01

02

03

04

05

06

¿Cuáles son estos principios de diseño?

(*) https://en.wikipedia.org/wiki/Conway%27s_law

(**) https://martinfowler.com/articles/microservices.html


El uso de containers ofrece unos niveles de estandarización y seguridad que habilitan reducir drásticamente el time to market

Container is the new .exe

Todo el SW productivo se ejecuta en

containers. Unifica los mecanismos de

despliegue, operación y mejora el

aprovechamiento de la infraestructura

Gestión de la configuración en docker.

Patrón sidecar*, la configuración como

parte de la versión del servicio

La infraestructura se define y

ejecuta utilizando containers.

Docker es la herramienta para la

construcción CI/CD. Habilita la

reproducibilidad, portabilidad y

versionado


ECS como orquestador de contenedores

Curva de aprendizaje rápida.

Microservicios en producción a tres

clicks de distancia

Seguridad. El modo de red aws-vpc

nos permite segmentar roles y security

groups a nivel de container.

Totalmente gestionado. Mínima

necesidad de operación: evita

cambios de versiones, recovery,

parches de seguridad...

Escalable y disponible. Múltiples

zonas de disponibilidad y fácil escalado

con grupos de autoescalado

Maximizar el uso de la plataforma nos permite enfocarnos en las necesidades de negocio


Arquitectura de sistemas

Es necesario conocer y seguir los estándares y las buenas prácticas del proveedor cloud


Conclusiones


El uso de containers permite alcanzar niveles de estandarización y seguridad que habilitan reducir drásticamente el time to market y el riesgo operacional

La automatización habilita minimizar la inversión en tiempo y coste en operación

¡Usa la plataforma! Maximizar el uso de la plataforma nos permite enfocarnos en el core de nuestro de negocio

Conclusiones y aprendizajes


Thank you!https://aws.amazon.com/es/about-aws/events/eventos-es/

@awscloud_es

https://aws.amazon.com/es/about-aws/events/eventos-es/

Documents

Portable Applications - Containers on AWS - …...Portable Applications - Containers on AWS October 2018 David Sanz, Solutions Architect, Amazon Web Services Fernando García, Product