Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
L
Lab-Terraform
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
LSDS
Teaching
Bachelor
Cloud-and-Deployment
Lab-Terraform
Commits
cff753ef
Unverified
Commit
cff753ef
authored
6 months ago
by
Marco Emilio "sphakka" Poleggi
Browse files
Options
Downloads
Patches
Plain Diff
More tips
Signed-off-by:
Marco Emilio "sphakka" Poleggi
<
marcoep@ieee.org
>
parent
5f62aa13
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
SwitchEngines/README.md
+15
-12
15 additions, 12 deletions
SwitchEngines/README.md
with
15 additions
and
12 deletions
SwitchEngines/README.md
+
15
−
12
View file @
cff753ef
...
@@ -156,7 +156,8 @@ resource "openstack_compute_instance_v2" "app_server" {
...
@@ -156,7 +156,8 @@ resource "openstack_compute_instance_v2" "app_server" {
Indeed, all TF files inside a directory constitute a "module". In our case,
Indeed, all TF files inside a directory constitute a "module". In our case,
that's the "root" module.
that's the "root" module.
You shall replace all
`<...>`
tokens with actual values.
:hammer_and_wrench:
**Over to you now.**
You shall replace all
`<...>`
tokens with actual values.
:bulb: If you want use explicit provider resource configuration, the values
:bulb: If you want use explicit provider resource configuration, the values
shall match those in file
`~/.config/openstack/clouds.yaml`
.
shall match those in file
`~/.config/openstack/clouds.yaml`
.
...
@@ -536,9 +537,9 @@ Did you try to SSH into the instance you created via TF? It cannot work,
...
@@ -536,9 +537,9 @@ Did you try to SSH into the instance you created via TF? It cannot work,
because we did not instructed TF about networking, login, users, keys or
because we did not instructed TF about networking, login, users, keys or
anything else.
anything else.
**This is left to you as an exercise.**
With reference to the official TF documentation for the
[
OpenStack
:hammer_and_wrench:
**Over to you now.**
With reference to the official TF
documentation for the
[
OpenStack
provider
](
https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/
)
,
provider
](
https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/
)
,
you shall:
you shall:
...
@@ -597,7 +598,7 @@ lcl$ ssh -i keys/tf-cloud-init -o IdentitiesOnly=yes $(terraform output -raw ssh
...
@@ -597,7 +598,7 @@ lcl$ ssh -i keys/tf-cloud-init -o IdentitiesOnly=yes $(terraform output -raw ssh
Now you can provision an instance and have SSH access to it. Let's write a plan variant to provision a cluster of 2 instances.
Now you can provision an instance and have SSH access to it. Let's write a plan variant to provision a cluster of 2 instances.
You shall:
:hammer_and_wrench:
**Over to you now.**
You shall:
1.
Declare a variable or
1.
Declare a variable or
[
_local_
](
https://developer.hashicorp.com/terraform/language/values/locals
)
[
_local_
](
https://developer.hashicorp.com/terraform/language/values/locals
)
...
@@ -730,7 +731,7 @@ data "cloudinit_config" "my_config" {
...
@@ -730,7 +731,7 @@ data "cloudinit_config" "my_config" {
filename = "file-1"
filename = "file-1"
content_type = "text/cloud-config"
content_type = "text/cloud-config"
content = file("file-1.yml")
content = file("file-1.yml")
merge_type = "list(append)+dict(no_replace,recurse_list)"
merge_type = "list(append)+dict(no_replace,recurse_list)"
}
}
part {
part {
...
@@ -748,7 +749,7 @@ data "cloudinit_config" "my_config" {
...
@@ -748,7 +749,7 @@ data "cloudinit_config" "my_config" {
*
The
*merged*
result of the whole block is provided by the read-only
*
The
*merged*
result of the whole block is provided by the read-only
attribute:
`data.cloudinit_config.my_config.rendered`
.
attribute:
`data.cloudinit_config.my_config.rendered`
.
:
:hammer_and_wrench:
:
**Over to you now.**
You shall:
:hammer_and_wrench:
**Over to you now.**
You shall:
1.
Split your cloud-init YAML file above into 2 files:
1.
Split your cloud-init YAML file above into 2 files:
-
`conf/cloud-init.users.yaml`
with basic user-related configuration, and
-
`conf/cloud-init.users.yaml`
with basic user-related configuration, and
...
@@ -774,7 +775,7 @@ before starting this exercise.**
...
@@ -774,7 +775,7 @@ before starting this exercise.**
Now you have all the skills to provision your micro cloud infrastructure based
Now you have all the skills to provision your micro cloud infrastructure based
on KinD.
on KinD.
You shall:
:hammer_and_wrench:
**Over to you now.**
You shall:
1.
Modify your
`main.tf`
to use a more capable flavor instance for your
1.
Modify your
`main.tf`
to use a more capable flavor instance for your
`app_server`
, like a
`m1.medium`
or
`c1.large`
.
`app_server`
, like a
`m1.medium`
or
`c1.large`
.
...
@@ -783,7 +784,7 @@ You shall:
...
@@ -783,7 +784,7 @@ You shall:
package, install
`kubectl`
and
`kind`
via explicit
`runcmd`
scripts;
package, install
`kubectl`
and
`kind`
via explicit
`runcmd`
scripts;
-
add any needed extra group for the default user.
-
add any needed extra group for the default user.
Run again terraform apply, wait a couple of minutes to let the installation of
Run again terraform apply,
**
wait a couple of minutes
**
to let the installation of
all extra packages to complete, then connect to your instance.
all extra packages to complete, then connect to your instance.
Since KinD is not designed for remote use, you'll have to create your cluster
Since KinD is not designed for remote use, you'll have to create your cluster
...
@@ -838,8 +839,8 @@ following:
...
@@ -838,8 +839,8 @@ following:
provisioners.
provisioners.
You shall extend your
`main.tf`
plan
recipe with:
:hammer_and_wrench:
**Over to you now.**
You shall extend your
`main.tf`
plan
recipe with:
1.
At least one
`terraform_data`
resource declaration that encapsulate all the service
1.
At least one
`terraform_data`
resource declaration that encapsulate all the service
deployment logic: transferring files and sending commands.
deployment logic: transferring files and sending commands.
1.
Inside your
`terraform_data`
declaration:
1.
Inside your
`terraform_data`
declaration:
...
@@ -877,11 +878,10 @@ resource "terraform_data" "kind_cluster" {
...
@@ -877,11 +878,10 @@ resource "terraform_data" "kind_cluster" {
provisioner
"remote-exec"
{
provisioner
"remote-exec"
{
inline
=
[
inline
=
[
"shell command"
,
"shell command"
,
...
,
...
]
]
}
}
}
}
```
```
:bulb: Please mind that:
:bulb: Please mind that:
...
@@ -890,6 +890,9 @@ resource "terraform_data" "kind_cluster" {
...
@@ -890,6 +890,9 @@ resource "terraform_data" "kind_cluster" {
-
For a maximum of flexibility, it is advisable to write 2
-
For a maximum of flexibility, it is advisable to write 2
`terraform_data`
blocks: one for KinD and another for MetalLB. This way you
`terraform_data`
blocks: one for KinD and another for MetalLB. This way you
can test the creation of the two resources separately.
can test the creation of the two resources separately.
-
Since the lines of a
`remote-exec`
are merged into a script, it is wise to
start it with the command
`set -o errexit`
, so that the whole script exits
at the first error.
:warning: You will probably hit some thorny issues:
:warning: You will probably hit some thorny issues:
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment