Skip to content

Latest commit

 

History

History
172 lines (107 loc) · 8.32 KB

workshop.md

File metadata and controls

172 lines (107 loc) · 8.32 KB
Raw

1. Omnia Radix Workshop 2

The purpose of the workshop is to give a general and hands-on introduction to Radix.

1.1. Pre-requisites

  • Have access to the Radix Playground
  • Account on github.com
  • Git installed and working locally against github.com
  • Docker running locally
  • Node js eco system installed and running (Download Nodejs)
  • Local dev. environment (IDE++)
  • Laptop that "works" on “Statoil Approved” WiFi. If not - know how to handle proxy fun for both Docker and local development environment

2.1. Part 1 - Register app in Radix

Scenario

Your team has just started developing an application that generates secure passwords and displayes it in a web client. To get feedback from end users as fast as possible, your team have chosen to do UI first development. To facilitate a short feedback loop, automated CI/CD (automate build/deploy) of the application needs to be setup, ending with a public url that users can test.

An OpenAPI specification has been agreed on with the API team, so we'll begin with mocking data for the UI. Radix has been choosen as platform, seemingly perfect for the scenario.

2.1.1. Getting started

  1. Fork repository to your home on github. Consider choosing an alternative name for the repository
  2. Clone your newly forked repository down to your developer laptop

2.1.2. Exploring the WWW app

  1. Move into the www folder and explore how to develop the WWW app using ReactJs and Node.js as well as Dockerizing the application.

2.1.3. Preparing for Radix

Important to know:

  1. The difference between platform user and application user
  2. Important terminology: application, environments,components, and replicas Important Radix Concepts
  3. radixconfig.yaml - lives on the master branch and is your infrastrucure as code - drive your app in Radix.

2.1.4. Explore radixconfig.yaml

  1. Reading about radixconfig.yaml in docs
  2. Exploring the config file for the example app ./radixconfig.yaml

2.1.5. Creating the application on Radix

  1. Update the your app name of the application in radixconfig.yaml - it needs to be unique in cluster
  2. Follow the getting started guide or "just do it!"
  3. Do a change in app, commit and push to master to trigger the initial build and deploy to Radix. Examine web-hooks and reponse in Radix
  4. Verify that the app work on the public end-point it has been given.

2.2 Part 2 - connecting UI and API

Scenario

The UI is comming along nicely, and your team has started on the API. Next step is to integrate the API with the UI, so users can also start testing the logic behind password generation.

2.2.1. Exploring the Echo app

  1. Move into the echo folder and explore how to develop the Echo app using Node.js as well as Dockerizing the application.

2.2.2. Connect UI with Echo Api

  1. Move into UI and disable the use of Mock data.
  2. Run Echo API locally
  3. Run www locally
  4. Verify in log that requests are being handled by API

2.2.3. Update app in Radix

  1. Add Echo app to radixconfig.yaml
  2. Update nginx.conf to forward request to echo api
  3. Commit code to Master branch.
  4. Verify the changes in Radix. Look at the Radix Host name, which should jump between the two replicas we've setup for the API.

2.2.4. Update api

  1. Do a change on master branch either in the api or ui
  2. commit and push to master branch
  3. Verify that there is no downtime during the release of a new version

Radix run on top of Kubernetes, which support rolling updates. This means that traffic will not be routed to the newly deploy api before it is up and running.

2.3 Part 3 - setup prod environment

Scenario

The MVP of the application is done, and next step is to setup a production environment. There is sadly too few automated tests to support a clean Trunk base development, but we will do something similar.

We'll setup 2 new environments, QA and prod. A build/deploy to QA will be triggered by push to "release" branches. When the QA version has been verified its manually promoted to prod environment.

2.3.1. Multiple environments

Radix support connecting a branch to a specific environment. Let's explore this.

  1. Add two new environments in radixconfig.yaml file - QA and prod. QA should be built from release/* branch (whenever someone publish to a release/* branch).
  2. Commit and push changes to master branch, explore what's happening in Radix.

2.3.2 Deploy to QA

  1. Check out a new branch "release/0.1.0" from master branch
  2. Commit and push the new branch, explore what's happening in Radix.
  3. Verified that the application is running as expected in QA environment.

2.3.3 Promote to production

  1. Do a promotion of the deployment running in QA to prod environment.
  2. Verified that the application is running as expected in prod environment.

2.4 Part 4 - Authentication (optional)

Radix support refering to prebuild docker images. This can be used to introduce common services as proxies, caching, authentication etc. In this part we will explore how to reference an existing image to add OpenId Connect authentication to the application.

If there is time we will go through an example together during workshop.

2.4.1 Create an app in Azure AD

If you have access to create an app in Azure AD, you can perform this part. You can follow the instruction from example.

2.4.2 Update radixconfig with oauth_proxy

  1. Use OAuth proxy developed by pusher to add Authentication
  2. Update radixconfig file. See example on how it can be done
  3. Remember to disable the public endpoint for www component in radixconfig file (publicPort should not be set)
  4. Optional: get the authentication to work locally using docker-compose - the format is similar to radixconfig
  5. Commit & push to master branch to verify setup

2.5 Monitoring & Metrics

The Echo component is exposing metrics on the /metrics endpoint. These metrics are scraped by Prometheus and made available in Grafana. Consult the docs for Prometheus and Grafana for how to work with metrics and monitoring.

3. Typical questions

(Status as of September 2019)

  • Storage - databases
  • Authentication
  • Logging
  • Metrics - Monitoring
  • Radix CLI (Api)
  • Backup & Disaster recovery
  • Own domain names / urls for apps

3.1. Where to get started, get help, log issues or feature requests

3.1.1. Getting help

3.1.2. Getting started

3.1.3. Log issues & feature requests

It makes sense to examing existing issues and perhaps discuss on Slack prior to logging a new one

4 Next steps

  • The application is currently hosted under a *.radix.equinor.com domain. This is OK for now, but it has been identified that for the future we'll want our own *.equinor.com domain as is possible in Radix.
  • Move your own apps into Radix