Quick links : Home - Part 1 - Part 2 - Part 3 - Part 4 - Part 5
Part 5 - Codebase - Dependencies - Config - Backing services - Build, release, run - Processes - Port binding - Concurrency - Disposability - Dev/prod parity - Logs - Admin processes
Strictly separate build and run stages
In this workshop the approach presented naturally fits the build. release, run model advocated in the 12-factor methodology. The build stage takes the codebase and create a container, which is stored in a registry. The run stage will then take the required version of the registry and deploy it.
A Continuous Integration / Continuous Delivery (CI/CD) pipeline will often be used to automate the process. Where a delivery of code into the source control system will trigger a build to create a new version of the container and automatically deploy the newly created container to a staging system for testing.
The run stage is commonly managed by a cloud platform, such as RedHat OpenShift, which manages the application by pulling the required version of a container from the registry, providing the required configuration to the container, deploying the required number of instances of the container, monitoring the running containers and routing traffic to the container instances.
The starter Node-RED git repo has health check built in to allow a cloud environment to monitor the application using endpoints:
- /live
- /ready
- /health
[TODO - add minishift pipeline tutorial or demo ???????]
Part 5 - Codebase - Dependencies - Config - Backing services - Build, release, run - Processes - Port binding - Concurrency - Disposability - Dev/prod parity - Logs - Admin processes
Quick links : Home - Part 1 - Part 2 - Part 3 - Part 4 - Part 5