Verified Commit 7c944b54 authored by Michael Hofmann's avatar Michael Hofmann
Browse files

Restructure hacking part of documentation

Signed-off-by: Michael Hofmann's avatarMichael Hofmann <>
parent d92f9c1c
title: Background
description: >
Lots of background information about various aspects of the CKI setup
weight: 20
title: "Diagrams"
description: Various diagrams describing the CKI pipeline
title: "Cloud environments"
linkTitle: "Cloud"
description: Old documentation related to AWS, mostly out of date
title: "AWS Deployment"
description: A summary of the AWS deployment of the CKI pipeline
*This is a work in progress.*
The CKI infrastructure can be deployed on AWS.
The necessary tooling can be found in the [aws-deployment] repository on GitLab.
## Preparations
Before running the playbooks, be sure you are fully authenticated with AWS.
You must setup the following environment variables before starting any of the scripts:
- `GITLAB_URL`: URL of the GitLab instance to host the schedules and pipelines
- `GITLAB_PARENT_PROJECT`: GitLab parent project
- `GITLAB_TOKEN`: GitLab API token for the bot user that triggers pipelines
- `GITLAB_TOKEN_ADMIN_BOT`: maintainer-level GitLab API token to register
GitLab runners
- `GITLAB_TOKEN_REGISTRATION`: GitLab runner registration token
- `GITLAB_COM_SSH_ACCOUNTS`: space-separated list of usernames on
which ssh keys should be allowed for access to the GitLab runner
Verify that the `aws_region` is set properly in `vars.yml`.
The default region is `us-east-2` (Ohio).
Ensure Ansible and the `boto3` python module are installed.
## Deploying
Run the playbook with the following command:
ansible-playbook -i hosts PLAYBOOK_NAME
`PLAYBOOK_NAME` is one of the following:
- `deploy_iam.yml`: Deploy or update roles and policies
- `deploy_common_infrastructure.yml`: Deploy or update VPCs, S3 buckets, and
EC2 security groups
- `deploy_gitlab_runner.yml`: Deploy or update the gitlab-runner
- `deploy_gitlab_schedules.yml`: Deploy or update the GitLab CI/CD schedules
- `deploy_tear_down.yml`: Remove all EC2 instances and common infrastructure
Normally, the deployment is scoped to the user name and the subnet defined in
`vars.yml`. For production, override the `cki_environment` and `cki_cidr_base`
variables, e.g. with
ansible-playbook \
deploy_gitlab_runner.yml \
-i hosts \
-e cki_cidr_base=10.10 \
-e cki_environment=production
To apply a certain role to a host at a fixed IP address, you can use
ansible-playbook \
deploy_gitlab_runner.yml \
-i gitlab_runner, \
-e ansible_host=
title: "Inventory"
description: A description of the different pieces that make up the CKI project
weight: 30
weight: 40
The CKI kernel testing setup consists of various pieces that roughly fit into
title: Operations
description: Descriptions of the procedures for various tasks
weight: 20
......@@ -2,7 +2,7 @@
title: "Request For Comments (RFC)"
linkTitle: "RFCs"
description: Lightweight feedback mechanism for the CKI project
weight: 15
weight: 30
autonumbering: true
......@@ -220,6 +220,6 @@ There are two issues with this approach:
[retrigger MR pipelines manually]:
[retrigger MR pipelines manually]: ../../operations/
<!-- vi: set spell spelllang=en: -->
title: "Cheat sheet"
title: "Create diagrams"
description: >
How to add or modify diagrams
......@@ -258,7 +258,7 @@ please refer to the [pipeline triggers] documentation.
[pipeline triggers]:
[share the same code]:
[pipeline triggers]:
[container documentation]: ../hacking/contributing/
[container documentation]: ../hacking/background/
[kpet tree selection script]:
[living in GitLab]: gitlab-mr-testing
[Data Warehouse]:
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment