Industry 4.0 App Readiness¶
Docker Compose ist die Technologie der Wahl, wenn es um die Aggregation der Bestandteile einer App geht. Da Docker Compose nur ein Werkzeug ist und nicht ein elementarer Baustein der Plattform kann es durch z.B. Kubernetes Helm Charts oder Rancherfiles ersetzt werden, ohne die Struktur der App zu beeinflussen.
Zu tun
Work in progress
App Containers (Docker Subsystem)¶
Das Git-Repository nutzt die ScaleIT-Ordnerstruktur (Domain Apps, Sidecars Ordner)
<app_name>
├── docker-compose.yml
├── dc.build.yml [optional]
├── .env.default
├── .env.test.default [optional]
├── .env.staging.default [optional]
├── .env.production.default [optional]
├── README
├── Resources/
| ├── Documentation/
| ├── Rancher/
| | ├── catalogIcon-<app1>.svg //jpg,png or other format ok
| | ├── appHubIcon-<app1>.svg //jpg,png or other format ok
| | ├── config.yml // meta-data about the app
| | └── Screenshots/ // App Screenshots
| | | └── 1.jpg
| | └── Versions/
| | . └── 0/
| | . . └── docker-compose.yml // compose version 2 due to compatibility reasons
| | . . └── rancher-compose.yml
| └── Documentation/
| └── README
├── Domain Software/
| ├── DomainContainer1/
| | ├── Dockerfile
| | └── <some other files>
| └── DomainContainer2/
| └── Dockerfile
└── Platform Sidecars/ [optional]
. ├── SidecarContainer1/
. | ├── Dockerfile
. | └── <some other files>
. └── SidecarContainer2/
. . └── Dockerfile
Dockerfile -> Docker Build -> Image: includes all needed Dependencies (Self Contained-ness/in sich geschlossen)
Docker Compose declares all needed Services (no other services will be started within the app)
The App can be started with a single „click“ (docker-compose up)
Docker Compose declares all needed Volumes (Data Volume + Log Volume)
The App can be stopped and restarted without domain data loss or (docker-compose stop/restart)
The App containers can be deleted without domain data loss (docker-compose down)
The App containers can be replaced by new containers without domain data loss or corruption (docker-compose down + build + up)
The timezone set for the container is UTC. See Time Zone Details, Why UTC?
Data Migration check may be necessary
The created containers shut down properly (no PID 1 zombies)
Adhere to the Dockerfile best practices
App Interfaces¶
Sinn dieser Interfaces: „Eine Web-UI zu haben um Administration und Datensicht auf die App und das was sie macht zu erlauben“.
Administration Endpoint /admin
- admin/config
- admin/doc
- admin/log
- admin/status
User Endpoint /user
- user/doc
- user/status
Developer Endpoint /dev
- dev/doc
- dev/rest
- dev/swagger.yaml
Zu tun
Insert Link to Spec as Swagger file
App Catalog Entry¶
A separate git repository contains the meta-data from the Resources/Store directory in a Rancher-compatible directory structure
Auto-generated entries for this repository (e.g. git post commit hooks that push meta-data to this app-store repository)
-- templates
|-- <app1>
| |-- 0 // App1-Version 0
| | |-- docker-compose.yml
| | |-- rancher-compose.yml
| | |-- answers.txt //environment variables for rancher-compose
| | |-- README.md
| |-- 1 // App-Version 1
| | |-- docker-compose.yml
| | |-- rancher-compose.yml
| | |-- README.md
| |-- catalogIcon-<app1>.svg //jpg or other format ok
| |-- appHubIcon-<app1>.svg //jpg or other format ok
| |-- config.yml // meta-data about the app
| |-- README.md
|-- <app2>
| |-- 0 // App2-Version 0
...
Contents of the config.yml
name: # Name of the Catalog Entry
description: |
# Description of the Catalog Entry
version: # Version of the Catalog to be used
category: # Category to be used for searching catalog entries
maintainer: # The maintainer of the catalog entry
license: # The license
projectURL: # A URL related to the catalog entry
This information is strongly inspired by the Rancher Catalog system: [http://rancher.com/docs/rancher/v1.2/en/catalog/private-catalog/](http://rancher.com/docs/rancher/v1.2/en/catalog/private-catalog/)
A catalog entry generator can be found here: [https://github.com/slashgear/generator-rancher-catalog](https://github.com/slashgear/generator-rancher-catalog)
App Documentation¶
Readme states the purpose of the App
Readme lists the services and describes them shortly
Playbook includes App Lifecycle commands (pull, start, stop, upgrade)
Architecture Diagramm (eg. UML Deployment Diagramm)
Readme includes logo and screenshots
App Requirements (RAM, CPU, HDD)
### ScaleIT App Compliance Level
App has the networking information included (routing address)
Software Engineering¶
Reactive Design (App Richtlinien)
[https://projects.teco.edu/projects/scaleit-ap2/wiki/Richtlinien_App-Entwicklung]( https://projects.teco.edu/projects/scaleit-ap2/wiki/Richtlinien_App-Entwicklung)
Development Process¶
Time Zone Details, Why UTC?¶
Why Not {PST, GMT, PDT, etc}?[#serverutc]_
- UTC has no Daylight Savings
- Uniform time across all sites, factories and offices
- Decreases data corruption chances due to inconsistent time zones
- Standardized time across all our Apps will ensure logs, databases and all components relying on the time will function in a predictibale and interoperable way.
Bemerkung
- This will move the problem up into the UI layer. We recommend working with UTC inside the App logic and converting UTC to local time only on the user interface.
- Tech Tip: Using the angular DatePipe in the UI will help you achieve this easily [3]. Look in the programming language of your choice to find similar useful features.
[1] | UTC in a glance, https://www.timeanddate.com/worldclock/timezone/utc |
[2] | An argument for UTC, http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html |
[3] | Angular DatePipe, https://angular.io/api/common/DatePipe |