-
Notifications
You must be signed in to change notification settings - Fork 1
SymbIoteCloud from docker
- Cloud Deployment
This document explains how to run the symbIoTe cloud for L1/L2 integration depending on your needs. There are two ways to run docker:
- directly (on linux)
- docker-machine (previously boot2docker) - in virtual machine
This influences how to expose port in virtual machine to local machine. So, there are 2 ways to run ngrok and 2 ways to expose port in production environment.
Install following:
- docker (18.03.x),
- docker-compose (1.21.x),
- docker-machine (0.14.x),
- bash,
- curl,
- wget
Before registration you need to know if you are going to use server:
- with public IP address (production server) or
- with local address and tunneling to public by using ngrok (hackaton environment).
If you are using public IP address then you need to obtain HTTPS certificate. One way to do that is by using let's encrypt or some other provider (see documentation)
Otherwise you will use hackaton environment with ngrok (see documentation)
Next is to register platform in symbIoTe core. Here is documentation.
When getting the platform configuration you have to enter the following options:
- Compliance Level: L1 or L2 (depending on the compliance level desired)
- Deployment Type: Docker
IMPORTANT NOTE
Starting from release 3.1.0, there are 2 extra steps needed as noted below.
mkdir symbiote-cloud
- change to that directory (e.g.
cd symbiote-cloud
) - unzip the configuration files to the directory from the .zip downloaded earlier
- enter the CloudConfigProperties folder, make any changes (if) you want in the properties (e.g. rabbitMQ credentials) and commit the changes (Starting from release 3.1.0):
cd CloudConfigProperties
git remote rm origin
git config user.email "[email protected]"
git config user.name "Your Name"
git commit -am "Platform configuration"
cd ..
- create a docker volume to hold the CloudConfigProperties. Replace the {docker stack name} (e.g. symbiote-app) in the command below with your selected docker stack name (Starting from release 3.1.0):
docker container run --rm -v $PWD/CloudConfigProperties:/source -v {docker stack name}_symbiote-vol-config:/home/CloudConfigProperties -w /source alpine cp -r . /home/CloudConfigProperties/
- copy the docker-compose files for the desired compliance level:
- docker-compose-swarm-L1.yml and docker-compose-prod-swarm-L1.yml for L1 integration. Also, docker-compose-ngrok-swarm-L1.yml to run ngrok.
- docker-compose-swarm-L2.yml and docker-compose-prod-swarm-L2.yml for L2 integration. Also, docker-compose-ngrok-swarm-L2.yml to run ngrok.
- Uncomment and configure the proxy settings in the docker compose files for L1/L2 (docker-compose-swarm-L1.yml, docker-compose-swarm-L2.yml) if you are behind a proxy.
- example of implementation of ResourceAccessProxyPlugin:
- In some YML files are parts that are configuring PROXY. If you use proxy it should be uncommented and changed according to your proxy server and if you do not use it please comment those parts by putting # in the beginning of line. Parameters related to proxy are: JAVA_HTTP_PROXY, JAVA_HTTPS_PROXY, JAVA_SOCKS_PROXY and JAVA_NON_PROXY_HOSTS.
Here is table with instructions based on preferred deployment:
Environment | docker directly (on linux) | docker-machine |
---|---|---|
production environment | section 2.1 | section 2.2 |
hackathon environment (ngrok) | section 2.3 | section 2.4 |
IMOPRTANT NOTE:
The compose files have been configured to block incoming external traffic to components other than the nginx when docker compose is used. However, this is not possible when using docker swarm. Consequently, the Platform Owners need to block the incoming external traffic to components by using other means e.g. iptables in all the swarm nodes.
-
Obtain certificate as described in https://github.com/symbiote-h2020/SymbioteCloud/wiki/2.1-Configuration-of-NGINX#2111-obtaining-the-ssl-certificate or by some other provider
- Create dir nginx-certificates
$ mkdir nginx-certificates
- Copy certificates to nginx-certificates
- Create dir nginx-certificates
$ sudo cp /etc/letsencrypt/live/{your domain}/fullchain.pem nginx-certificates/
$ sudo cp /etc/letsencrypt/live/{your domain}/privkey.pem nginx-certificates/
$ sudo chown -R {user}:{group} nginx-certificates
-
Run
docker swarm init
if the node is not a swarm manager. We use the swarm mode so that secrets are encrypted during transit and at rest. Docker secrets are only available to swarm services and not to standalone containers. -
Run:
-
docker stack deploy -c docker-compose-swarm-L1.yml -c docker-compose-prod-swarm-L1.yml -c docker-compose-swarm-custom.yml symbiote-app
to deploy the application in L1 compliance or -
docker stack deploy -c docker-compose-swarm-L2.yml -c docker-compose-prod-swarm-L2.yml -c docker-compose-swarm-custom.yml symbiote-app
for L2 compliance. You can change the name of the service stack (symbiote-app) to be used.
-
-
You can run:
-
docker stack ls
to list the stack and check the number of services used. -
docker image ls
to check that all images have been created. It may take a while to pull all the images from DockerHub for the first time. -
docker service ls
to list the services and check their status. Wait until the actual number of tasks (replicas) for each service is not 0. -
docker logs <container_name> -f
to get access to and follow the logs of a service. A component is ready when a message similar to 'Started <component_name> in 105.045 seconds (JVM running for 112.933)' appears in the logs of the container. We recommend to look for logs in containers:config
,aam
andrap
. NOTE: look for helper shell scripts. -
sudo service docker restart
to restart the docker service if needed and repeat the steps.
-
-
Run
docker stack rm symbiote-app
to stop the application and remove the service stack. Services, networks, and secrets associated with the stack will be removed. -
You can run
docker swarm leave --force
to leave the swarm.
- Obtain certificate as described previously
- The following command maps
- port 443 in default docker-machine (127.0.0.1:443) to
- local computer at port 443 on all interfaces (0.0.0.0:443)
docker-machine ssh default -L 0.0.0.0:443:127.0.0.1:443
- Run steps 2-6 as described previously in Section 2.1.
Before starting with hackathon environment you need to install ngrok (https://github.com/symbiote-h2020/SymbioteCloud/wiki/2.1-Configuration-of-NGINX#2121-ngrok).
- Run
docker swarm init
if the node is not a swarm manager. We use the swarm mode so that secrets are encrypted during transit and at rest. Docker secrets are only available to swarm services and not to standalone containers. - Run
-
docker stack deploy -c docker-compose-swarm-L1.yml -c docker-compose-ngrok-swarm-L1.yml -c docker-compose-swarm-custom.yml symbiote-app
to deploy the application in L1 compliance or -
docker stack deploy -c docker-compose-swarm-L2.yml -c docker-compose-ngrok-swarm-L2.yml -c docker-compose-swarm-custom.yml symbiote-app
for L2 compliance.
-
- You can run:
-
docker stack ls
to list the stack and check the number of services used. -
docker image ls
to check that all images have been created. It may take a while to pull all the images from DockerHub for the first time. -
docker service ls
to list the services and check their status. Wait until the actual number of tasks (replicas) for each service is not 0. -
docker logs <container_name> -f
to get access to and follow the logs of a service. A component is ready when a message similar to 'Started <component_name> in 105.045 seconds (JVM running for 112.933)' appears in the logs of the container. We recommend to look for logs in containers:config
,aam
andrap
. NOTE: look for helper shell scripts. -
sudo service docker restart
to restart the docker service if needed and repeat the steps.
-
- Run
docker stack rm symbiote-app
to stop the application and remove the service stack. Services, networks, and secrets associated with the stack will be removed.
Before starting with hackathon environment you need to install ngrok (https://github.com/symbiote-h2020/SymbioteCloud/wiki/2.1-Configuration-of-NGINX#2121-ngrok).
- Run
docker swarm init
if the node is not a swarm manager. We use the swarm mode so that secrets are encrypted during transit and at rest. Docker secrets are only available to swarm services and not to standalone containers. - Run
docker-machine ssh default -L 0.0.0.0:8102:127.0.0.1:8102
for mapping port in virtual machine to this computer. - Run
-
docker stack deploy -c docker-compose-swarm-L1.yml -c docker-compose-ngrok-swarm-L1.yml -c docker-compose-swarm-custom.yml symbiote-app
to deploy the application in L1 compliance or -
docker stack deploy -c docker-compose-swarm-L2.yml -c docker-compose-ngrok-swarm-L2.yml -c docker-compose-swarm-custom.yml symbiote-app
for L2 compliance.
-
- You can run:
-
docker stack ls
to list the stack and check the number of services used. -
docker image ls
to check that all images have been created. It may take a while to pull all the images from DockerHub for the first time. -
docker service ls
to list the services and check their status. Wait until the actual number of tasks (replicas) for each service is not 0. -
docker logs <container_name> -f
to get access to and follow the logs of a service. A component is ready when a message similar to 'Started <component_name> in 105.045 seconds (JVM running for 112.933)' appears in the logs of the container. We recommend to look for logs in containers:config
,aam
andrap
. NOTE: look for helper shell scripts. -
sudo service docker restart
to restart the docker service if needed and repeat the steps.
-
- Run
docker stack rm symbiote-app
to stop the application and remove the service stack. Services, networks, and secrets associated with the stack will be removed.
During development and testing of RAP plugin it is convenient to run it in IDE on local machine. In that case follow steps in this document.
When you are finished with your custom RAP plugin and you have tested it (explained in section 4.4). Then you need to deploy it in docker environment. You need to do following:
- Create docker image from builded jar
- Upload image to machine where is running docker implementation
- you can export image to file, transfer file to machine with docker implementation and import image or
- you can upload image to docker hub and use image from there
- change docker-compose-swarm-custom.yml to use your image
- restart docker swarm stack
In order to easily check logs in docker containers and to run commands to in specific container we have prepared two scripts:
-
dl <container name>
- print logs in container which in name has container name provided. E.g.dl aam
-
dsh <container name>
- run bash in container which in name has container name provided. E.g.dsh aam
Here is script that you can add to .bashrc
or .zshrc
:
# Docker logs - argument is partial name of the container. It must be just one container with that name
function dl() {
docker logs $(docker ps -f name=$1 --format "{{.ID}}") -f
}
# Docker shell - argument is partial name of the container. It must be just one container with that name
function dsh() {
docker exec -it -e "TERM=xterm-256color" $(docker ps -f name=$1 --format "{{.ID}}") /bin/bash
}
Getting Started
Migration to 3.0.0
Migration to Docker
-
Preparation steps
1.1. Register user and configure platform in symbIoTe Core
1.2. Installation of required tools for symbIoTe platform components
1.3. Downloading jars
1.4. Downloading sources -
Configuring and starting components
2.1. Configuration of NGINX
2.2. Starting third party tools that are prerequisite for symbIoTe
2.3. Starting (generic) symbIoTe Cloud components
2.4. Configuration of cloud components
2.4.1. Starting symbIoTe Cloud components
2.5. Setting up the Platform Authentication and Authorization Manager (PAAM)
2.6. Starting Registration Handler and resource management
2.7. Set up of Resource Access Proxy
2.8. Manage resources
2.9. Set up of the Monitoring component
2.10. Other configuration topics -
Test integrated resource
3.1. Security
3.2. Search for resources
3.3. Obtaining resource access URL
3.4. Accessing the resource and actuating and invoking service for default (dummy) resources -
Creating RAP plugin
4.1. Customizing internal RAP plugin
4.2. Using RAP plugin starter
4.3. Creating RAP plugin in other languages -
Resource Description Examples
5.1. JSON Description Examples
5.2. RDF Description Examples - Preparation for L2 compliance
-
Configuring and starting components for L2
7.1. Starting Federation Manager
7.2. Starting Subscription Manager
7.3. Starting Platform Registry
7.4. Starting Trust Manager
7.5. Starting Bartering And Trading
7.6. Starting SLA Manager
7.7. Create a federation
7.8. Manage resources in L2
7.9. Register Subscription - Test Integrated L2 Resources
- Developing symbIoTe enabled apps