Skip to content

Commit 2837d25

Browse files
gxbengxben
committed
doc: create region
1 parent f69d540 commit 2837d25

2 files changed

Lines changed: 200 additions & 0 deletions

File tree

‎content/en/docs/getting-started/create-kiwi.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
title: Provisioning Kiwi
3+
description: Let's provision our Kiwi instances
4+
weight: 6
5+
---

‎content/en/docs/getting-started/create-region.md‎

Lines changed: 195 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,3 +3,198 @@ title: Create Your First Region
33
description: Let's setup a new region and its Kiwi and Kaktus instances
44
weight: 5
55
---
6+
7+
Orchestrator being ready, we can now boostrap our first region.
8+
9+
Let's take the following assumptions for the rest of this tutorial:
10+
11+
- The Kowabunga region is to be called **eu-west**.
12+
- The region will have a single zone named **eu-west-a**.
13+
- It'll feature 2 **Kiwi** and 3 **Kaktus** instances.
14+
15+
Back on the TF configuration, let's use the following:
16+
17+
```hcl
18+
locals {
19+
eu-west = {
20+
desc = "Europe West"
21+
22+
zones = {
23+
"eu-west-a" = {
24+
id = "A"
25+
}
26+
}
27+
}
28+
}
29+
30+
resource "kowabunga_region" "eu-west" {
31+
name = "eu-west"
32+
desc = local.eu-west.desc
33+
}
34+
35+
resource "kowabunga_zone" "eu-west" {
36+
for_each = local.eu-west.zones
37+
region = kowabunga_region.eu-west.id
38+
name = each.key
39+
desc = "${local.eu-west.desc} - Zone ${each.value.id}"
40+
}
41+
```
42+
43+
And apply:
44+
45+
```sh
46+
$ kobra tf apply
47+
```
48+
49+
Nothing really complex here to be fair, we're just using **Kahuna**'s API to register the region and its associated zone.
50+
51+
Now, we'll register the 2 **Kiwi** instances and 3 **Kaktus** ones. Please note that:
52+
53+
- we'll extend the TF **locals** definition for that.
54+
- **Kiwi** is to be associated to the global region.
55+
- while **Kaktus** is ti be associated to the region's zone.
56+
57+
Let's start by registering one Kiwi and 2 associated agents:
58+
59+
```hcl
60+
locals {
61+
eu-west = {
62+
63+
agents = {
64+
"kiwi-eu-west-1" = {
65+
desc = "Kiwi EU-WEST-1 Agent"
66+
type = "Kiwi"
67+
}
68+
"kiwi-eu-west-2" = {
69+
desc = "Kiwi EU-WEST-2 Agent"
70+
type = "Kiwi"
71+
}
72+
}
73+
74+
kiwi = {
75+
"kiwi-eu-west" = {
76+
desc = "Kiwi EU-WEST",
77+
agents = ["kiwi-eu-west-1", "kiwi-eu-west-2"]
78+
}
79+
}
80+
}
81+
}
82+
83+
resource "kowabunga_agent" "eu-west" {
84+
for_each = merge(local.eu-west.agents)
85+
name = each.key
86+
desc = "${local.eu-west.desc} - ${each.value.desc}"
87+
type = each.value.type
88+
}
89+
90+
resource "kowabunga_kiwi" "eu-west" {
91+
for_each = local.eu-west.kiwi
92+
region = kowabunga_region.eu-west.id
93+
name = each.key
94+
desc = "${local.eu-west.desc} - ${each.value.desc}"
95+
agents = [for agent in try(each.value.agents, []) : kowabunga_agent.eu-west[agent].id]
96+
}
97+
```
98+
99+
{{< alert color="warning" title="Warning" >}}
100+
Note that, despite have 2 **Kiwi** instances, from Kowabunga perspective, we're only registering one. This is because, the 2 instances are only used for high-availability and failover perspective. From service point of view, the region only has one single network gateway.
101+
102+
Despite that, each instance will have its own agent, to establish a WebSocket connection to **Kahuna** orchestrator.
103+
{{< /alert >}}
104+
105+
Let's continue with the 3 **Kaktus** instances declaration and their associated agents. Note that, this time, instances are associated to the zone itself, not the region.
106+
107+
{{< alert color="success" title="Information" >}}
108+
Note that **Kaktus** instance creaion/update takes 4 specific parameters into account:
109+
- **cpu_price** and **memory_price** are purely arbitrary values that express how much actual money is worth your metal infrastructure. These are used to compute virtual cost calculation later, when you'll be spwaning **Kompute** instances with vCPUs and vGB of RAM. Each server being different, it's fully okay to have different values here for your fleet.
110+
- **cpu_overcommit** and **memory_overcommit** define the [overcommit](https://en.wikipedia.org/wiki/Memory_overcommitment) ratio you accept your physical hosts to address. As for price, not every server is born equal. Some have hyper-threading, other don't. You may consider that a value of 3 or 4 is fine, other tend to be stricter and use 2 instead. The more you set the bar, the more virtual resources you'll be able to create but the less actual physical resources they'll be able to get.
111+
{{< /alert >}}
112+
113+
114+
```hcl
115+
locals {
116+
currency = "EUR"
117+
cpu_overcommit = 3
118+
memory_overcommit = 2
119+
120+
eu-west = {
121+
zones = {
122+
"eu-west-a" = {
123+
id = "A"
124+
125+
agents = {
126+
"kaktus-eu-west-a-1" = {
127+
desc = "Kaktus EU-WEST A-1 Agent"
128+
type = "Kaktus"
129+
}
130+
"kaktus-eu-west-a-2" = {
131+
desc = "Kaktus EU-WEST A-2 Agent"
132+
type = "Kaktus"
133+
}
134+
"kaktus-eu-west-a-3" = {
135+
desc = "Kaktus EU-WEST A-3 Agent"
136+
type = "Kaktus"
137+
}
138+
}
139+
140+
kaktuses = {
141+
"kaktus-eu-west-a-1" = {
142+
desc = "Kaktus EU-WEST A-1",
143+
cpu_cost = 500
144+
memory_cost = 200
145+
agents = ["kaktus-eu-west-a-1"]
146+
}
147+
"kaktus-eu-west-a-2" = {
148+
desc = "Kaktus EU-WEST A-2",
149+
cpu_cost = 500
150+
memory_cost = 200
151+
agents = ["kaktus-eu-west-a-2"]
152+
}
153+
"kaktus-eu-west-a-3" = {
154+
desc = "Kaktus A-3",
155+
cpu_cost = 500
156+
memory_cost = 200
157+
agents = ["kaktus-eu-west-a-3"]
158+
}
159+
}
160+
}
161+
}
162+
}
163+
}
164+
165+
resource "kowabunga_agent" "eu-west-a" {
166+
for_each = merge(local.eu-west.zones.eu-west-a.agents)
167+
name = each.key
168+
desc = "${local.eu-west.desc} - ${each.value.desc}"
169+
type = each.value.type
170+
}
171+
172+
resource "kowabunga_kaktus" "eu-west-a" {
173+
for_each = local.eu-west.zones.eu-west-a.kaktuses
174+
zone = kowabunga_zone.eu-west["eu-west-a"].id
175+
name = each.key
176+
desc = "${local.eu-west.desc} - ${each.value.desc}"
177+
cpu_price = each.value.cpu_cost
178+
memory_price = each.value.memory_cost
179+
currency = local.currency
180+
cpu_overcommit = try(each.value.cpu_overcommit, local.cpu_overcommit)
181+
memory_overcommit = try(each.value.memory_overcommit, local.memory_overcommit)
182+
agents = [for agent in try(each.value.agents, []) : kowabunga_agent.eu-west-a[agent].id]
183+
}
184+
```
185+
186+
And again, apply:
187+
188+
```sh
189+
$ kobra tf apply
190+
```
191+
192+
That done, **Kiwi** and **Kaktus** instances have been registered, but more essentially, their associated agents. For each newly created agent, you should have received an email (check the admin one you previously set in **Kahuna**'s configuration). Keep track of these emails, they contain one-time credentials about the agent identifier and it's associated API key.
193+
194+
This is the super secret thing that will allow them further to establish secure connection to **Kahuna** orchestrator. We're soon going to declare these credentials in Ansible's secrets so **Kiwi** and **Kaktus** instances can be provisioned accordingly.
195+
196+
{{< alert color="warning" title="Warning" >}}
197+
There's no way to recover the agent API key. It's never printed anywhere but on the email you just received. Even the database doesn't contain it. If one agent's API key is lost, you can either request a new one from API or destroy the agent and create a new one in-place.
198+
{{< /alert >}}
199+
200+
Let's continue and [provision our region's **Kiwi** instances](/docs/getting-started/create-kiwi/) !

0 commit comments

Comments
 (0)