Presentacin de PowerPoint

FIWARE Docker Container Service (FDCS)IntroductionKenneth NaginIBMnagin@il.ibm.com

This presentation introduces the FIWARE Docker Container Service and describes how you can start using the service.

Multi-Tenant Swarm

.

clientclientdocker-clidocker-composedocker api, any tool basedondocker-api

Docker Container Service

Keystone

Keystone apiexternal ipexternal ipNFSDocker Container Service (FDCS)

Key-ValueStorage

The FIWARE Docker Container Service., FDCS. Allows you to manage your docker containers, volumes, and networks remotely from your local Docker client. You do not have to worry about creating or managing docker hosts, since the service maintains a cluster of docker hosts that you can use.

Many tenants may share the services resources, but they are isolated from each other.

In this illustration we show a local Docker client remotely managing its Docker containers from a work station, but the containers are running on the FDCS cluster.

Most of the communication between the client and the service is through the Docker REST API.

But the client must get a valid token from FIWAREs Openstack Keystone Identity Management Service.

Once a valid token is obtained the client can use the docker cli or docker compose to create and deploy complex Docker services.

ContainerMulti-Tenant Isolation and Multi-Tenant Name Scoping

Tenant 1Docker Container Service

Keystone

Tenant 2Tenant 3

Multi-Tenant Swarm

The services tenants share docker host resources, but are isolated from each other!; We refer to this feature as Multi-Tenant Isolation.

The service also allows its tenants to use the same names to identify their resources without interfering with each other; We refer to this feature as Multi-Tenant Name Scoping.

Multi-Tenant Isolationeach tenant only sees its own containersTenant 2: create, run and view containersTenant 1: create, run, and view container

Tenant 1: only sees its containers

FDCS supports mulit-tenant isolation. FDCS allows many authorized FIWARE tenants to use the FDCS cluster, however the tenants are isolated from each other. Tenants can create docker resources, i.e. containers, networks, volumes, etc., but only the tenant that creates a docker resource may manage the resource. Tenants can not even see other tenants' resource let alone manage them.

Two tenants shown.Tenant 1 runs one Ubuntu container called tenant2-loop1 that launches a shell script that loops on itself. Tenant 2 runs two Ubuntu container called tenant2-loop1, tenant2-loop2 that launche their own shell script that loops on itself.

Each tenant only sees its own containers

Multi-Tenant Isolationeach tenant can only manage its own containersTenant 1: not allowed to remove container created by tenant 2Tenant 1: removes its containersTenant 1 and Tenant 2 view after rm attempts

Each tenant can only manage its own containers.

When tenant 1 tries to manage tenant 2s container FDCS returns an error.

Multi-Tenant Name Scopingtenant containers with same name Tenant 2: uses same container Tenant 1: creates, runs, and views a named container

FDCS supports mulit-tenant name scoping. This means tenants can assign the same name to their docker resources without interfering with each other. For instants two tenants could create a container with the same name. They can also reference their resources by name and FDCS will ensure that the reference is to the resource owned by the tenant.

Here we show that Tenant 1 and Tenant 2 have created containers using the same name, same-name-loop.

Tenant members share resources

Tenant members remove tenant 2 containersdocker-user-2 and docker-user-3 are both members of docker-tenant-2

Tenant member attaches to running containers

More than one user may belong to a Tenant.Tenant members share FDCS resource.

This slide illustrates two users that belong to docker-tenant-2.They both can view and manage docker-tenant-2s containers.

User defined overlay networks and nfs volumesMulti-Tenant Isolation and Multi-Tenant Name Scoping

Tenant 1Docker Container Service

Keystone

Tenant 2Tenant 3

nfsMulti-Tenant Swarm

The services tenants share docker host resources, but are isolated from each other!; We refer to this feature as Multi-Tenant Isolation.

The service also allows its tenants to use the same names to identify their resources without interfering with each other; We refer to this feature as Multi-Tenant Name Scoping.

> docker volume create d nfs myvolume name myvolumeUser defined overlay networks and nfs volumes> Docker network create d overlay isolated_nw

Docker-compose version 2User defined networks and volume support

We now show how docker compose can be used to create and link multi-container FIWARE applications.This slide shows the docker-compose.yml file for the FIWARE GE context broker, also known as orion,The yml file describes two containers mongo db and orion. Orion listens on port 1026, We could assign an external host port to pair with the container port, but in this case we allow docker to auto define the port.

docker-compose.yml: orion + mongodbv1: links and volume_from

mongodata: image: mongo:3.2 volumes: - /data/db command: /bin/echo "Data-only for mongo" mongo: image: mongo:3.2 volumes_from: - mongodata command: --nojournal orion: image: fiware/orion links: - mongo ports: - "1026" command: -dbhost mongo

This docker-compose example demonstrates a docker service assembled from docker images FIWARE/orion and mongo:3.2. The DB is made persistent on a user define NFS volume called mongodata. The orion container communicates with the mongo container over a user defined overlay network called front.

docker-compose.yml: orion + mongodbv2: user defined overlay networks and NFS volumesversion: '2'networks: front: driver: "overlay"volumes: mongodata:# external: true driver: "nfs"services: mongo: image: mongo:3.2 command: --nojournal networks: - front volumes: - mongodata:/data/db orion: image: fiware/orion ports: - "1026" networks: - front command: -dbhost mongo

This docker-compose example demonstrates a docker service assembled from docker images FIWARE/orion and mongo:3.2. The DB is made persistent on a user define NFS volume called mongodata. The orion container communicates with the mongo container over a user defined overlay network called front.

Use docker compose to bring up service/orion$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

/orion$ docker volume lsDRIVER VOLUME NAME

/orion$ docker network lsNETWORK ID NAME DRIVER

/orion$ docker-compose up -dCreating network "orion_front" with driver "overlay"Creating volume "orion_mongodata" with nfs driverCreating orion_orion_1Creating orion_mongo_1

Initially, there are no running containers, no user defined volumes and no user defined networks.

We launch the service with docker-compose up d

It creates an overlay network (orion_front) and the user defined nfs volume (orion_mongodata), and two contains (orion_orion_1 and orion_mongo_1).docker_compose prefixes the containers with the directory name from which it launches the docker-compose file. It also appends a number to the container names that is used when it scales out a service.

Service up and running on cluster~/orion$ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------------orion_mongo_1 /entrypoint.sh --nojournal Up 27017/tcp orion_orion_1 /usr/bin/contextBroker -fg ... Up 130.206.119.32:32768->1026/tcp

:~/orion$ docker psCONTAINER ID IMAGE STATUS NAMES40e14092eddf fiware/orion Up 8 minutes docker-host-3/orion_orion_159a647da904e mongo:3.2 Up 8 minutes docker-host-2/orion_mongo_1

Notice that containers are running on different docker hosts. The orion container is running on docker-host-3 and the mongo container is running on docker-host-2. They can interact with each other over their own private overlay network. Notice also that the orion container's port 1026 is mapped to the docoker-host-3's port 32768. Later we will run curl commands to orion using the host port mapping.

User defined volume and overlay network created/orion$ docker volume lsDRIVER VOLUME NAMEnfs orion_mongodatanfs orion_mongodata/orion$ docker network lsNETWORK ID NAME DRIVER1b651ad80f4b orion_front overlay

We look at the volume that was created. Notice that docker-compose also prefixes the volume name with directory name from which the docker-compose file was launched. Two volume entries appear because the same nfs volume is mounted to both hosts in the cluster.

/orion$ docker network inspect orion_front[ { "Name": "orion_front", "Id": "1b651ad80f4b9567626faba94accdf74aa77217d91258105525d56a2d5907426", "Scope": "global", "Driver": "overlay", "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "10.0.0.0/24", "Gateway": "10.0.0.1/24" } ] }, "Containers": { "c67fbd499135cf20aa301a5e9c9b8611330a64cf1ac5315ca47fde5b5a4ecf50": { "Name": "orion_orion_1", "EndpointID": "4d5111cb9303e61bf28f3a5209e788d2e33c9d3f1a5c29ebdfcce8a1503ddc9e", "MacAddress": "02:42:0a:00:00:02", "IPv4Address": "10.0.0.2/24", "IPv6Address": "" }, "cba077da484f4b5f9ff6b47721810e7660dce5979ed84636573626f28d97d533": { "Name": "orion_mongo_1", "EndpointID": "fde05d125ba6971218eff9b5092877f7c6e47b8baaa67d156be83957b43baeab", "MacAddress": "02:42:0a:00:00:03", "IPv4Address": "10.0.0.3/24", "IPv6Address": "" } }, "Options": {} }]

Notice that containers are running on different docker hosts. The orion container is running on docker-host-3 and the mongo container is running on docker-host-2. They can interact with each other over their own private overlay network. Notice also that the orion container's port 1026 is mapped to the docoker-host-3's port 32768. Later we will run curl commands to orion using the host port mapping.

/orion$ port=$(docker-compose port orion 1026)/orion$ curl $port/v2/entities[]

/orion$ curl ${port}/v2/entities -s -S --header 'Content-Type: application/json' -X POST -d @-