{"id":71235,"date":"2023-02-15T09:03:06","date_gmt":"2023-02-15T09:03:06","guid":{"rendered":"https:\/\/www.cryptocabaret.com\/?p=71235"},"modified":"2023-02-15T09:03:06","modified_gmt":"2023-02-15T09:03:06","slug":"manage-openstack-using-terraform-and-gitlab","status":"publish","type":"post","link":"https:\/\/www.cryptocabaret.com\/?p=71235","title":{"rendered":"Manage OpenStack using Terraform and GitLab"},"content":{"rendered":"

Manage OpenStack using Terraform and GitLab<\/span>
\najscanlas<\/a><\/span>
\nWed, 02\/15\/2023 – 03:00<\/span><\/p>\n

\n

One virtue of GitOps<\/a> is Infrastructure as Code. It encourages collaboration by using a shared configuration and policy repository. Using GitLab can further enhance collaboration in your OpenStack cluster. GitLab CI can serve as your source control and orchestration hub for CI\/CD, and it can even manage the state of Terraform.<\/p>\n

To achieve this, you need the following:<\/p>\n

    \n
  1. GitLab<\/a> account or instance.<\/li>\n
  2. Private OpenStack cluster. If you don’t have one, read my article Set up OpenStack on a Raspberry Pi cluster<\/a>.<\/li>\n
  3. A computer (preferably a container host).<\/li>\n<\/ol>\n

    GitLab and Terraform state<\/h2>\n

    The goal is to achieve collaboration through Terraform, so you need to have a centralized state file. GitLab has a managed state for Terraform. With this feature, you can enable individuals to manage OpenStack collaboratively.<\/p>\n

    Create a GitLab group and project<\/h2>\n

    Log in to GitLab, click on the hamburger menu, and click Groups<\/strong>\u2192View all groups<\/strong>.<\/p>\n

    \n
    \"view<\/div>\n
    Image by: <\/span><\/p>\n

    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n

    Create a group by clicking on New group <\/strong>and then on Create group<\/strong>.<\/p>\n

    \n
    \"Create<\/div>\n
    Image by: <\/span><\/p>\n

    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n

    Name the group to generate a unique group URL, and invite your team to work with you.<\/p>\n

    \n
    \"Name<\/div>\n
    Image by: <\/span><\/p>\n

    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n

    After creating a group, create a project by clicking Create new project<\/strong>, and then Create blank project<\/strong>:<\/p>\n

    \n
    \"Create<\/div>\n
    Image by: <\/span><\/p>\n

    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n

    Name your project. GitLab generates a unique project URL for you. This project contains the repository for your Terraform scripts and Terraform state.<\/p>\n

    Create a personal access token<\/h2>\n

    The repository needs a personal access token to manage this Terraform state. In your profile, select Edit Profile:<\/strong><\/p>\n

    \n
    \"Edit<\/div>\n
    Image by: <\/span><\/p>\n

    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n

    Click Access Token<\/strong> in the side panel to access a menu for creating an access token. Save your token because you can’t view it again.<\/p>\n

    \n
    \"Access<\/div>\n
    Image by: <\/span><\/p>\n

    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n

    Clone the empty repository<\/h2>\n

    On a computer with direct access to your OpenStack installation, clone the repository and then change to the resulting directory:<\/p>\n

    \n$ git clone git@gitlab.com:testgroup2170\/testproject.git\n\n$ cd testproject<\/code><\/pre>\n
    Create the backend .tf and provider file<\/h2>\n
    Create a backend file to configure GitLab as your state backend:<\/p>\n
    \n$ cat >> backend.tf <\/code><\/pre>\n
    This provider file pulls the provider for OpenStack:<\/p>\n
    \n$ cat >> provider.tf = 0.14.0\"\n  required_providers {\n    openstack = {\n      source  = \"terraform-provider-openstack\/openstack\"\n      version = \"1.49.0\"\n    }\n  }\n}\n\nprovider \"openstack\" {\n  user_name   = var.OS_USERNAME\n  tenant_name = var.OS_TENANT\n  password    = var.OS_PASSWORD\n  auth_url    = var.OS_AUTH_URL\n  region      = var.OS_REGION\n}\nEOF<\/code><\/pre>\n
    Because you’ve declared a variable in the provider, you must declare it in a variable file:<\/p>\n
    \n$ cat >> variables.tf <\/code><\/pre>\n
    Because you’re initially working locally, you must set those variables to make it work:<\/p>\n
    \n$ cat >> terraform.tfvars <\/code><\/pre>\n
    These details are available on your rc<\/code> file on OpenStack.<\/p>\n
    Initialize the project in Terraform<\/h2>\n
    Initializing the project is quite different because you need to tell Terraform to use GitLab as your state backend:<\/p>\n
    \nPROJECT_ID=\"\"\nTF_USERNAME=\"\"\nTF_PASSWORD=\"\"\nTF_STATE_NAME=\"\"\nTF_ADDRESS=\"https:\/\/gitlab.com\/api\/v4\/projects\/${PROJECT_ID}\/terraform\/state\/${TF_STATE_NAME}\"\n\n$ terraform init \n  -backend-config=address=${TF_ADDRESS} \n  -backend-config=lock_address=${TF_ADDRESS}\/lock \n  -backend-config=unlock_address=${TF_ADDRESS}\/lock \n  -backend-config=username=${TF_USERNAME} \n  -backend-config=password=${TF_PASSWORD} \n  -backend-config=lock_method=POST \n  -backend-config=unlock_method=DELETE \n  -backend-config=retry_wait_min=5<\/your-unique-state-name><\/gitlab-personal-access-token><\/gitlab-username><\/gitlab-project-id><\/code><\/pre>\n
    To view the gitlab-project-id<\/code>, look in the project details just above the Project Information<\/strong> tab in the side panel. It’s usually your project name.<\/p>\n
    \n
      \"Project<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    For me, it’s 42580143<\/code>.<\/p>\n
    Use your username for gitlab-username<\/code>. Mine is ajohnsc<\/code>.<\/p>\n
    The gitlab-personal-access-token<\/code> is the token you created earlier in this exercise. In this example, I use wwwwwwwwwwwwwwwwwwwww<\/code>. You can name your-unique-state-name<\/code> anything. I used homelab<\/code>.<\/p>\n
    Here is my initialization script:<\/p>\n
    \nPROJECT_ID=\"42580143\"\nTF_USERNAME=\"ajohnsc\"\nTF_PASSWORD=\"wwwwwwwwwwwwwwwwwwwww\"\nTF_STATE_NAME=\"homelab\"\nTF_ADDRESS=\"https:\/\/gitlab.com\/api\/v4\/projects\/${PROJECT_ID}\/terraform\/state\/${TF_STATE_NAME}\"<\/code><\/pre>\n
    To use the file:<\/p>\n
    \n$ terraform init \n  -backend-config=address=${TF_ADDRESS} \n  -backend-config=lock_address=${TF_ADDRESS}\/lock \n  -backend-config=unlock_address=${TF_ADDRESS}\/lock \n  -backend-config=username=${TF_USERNAME} \n  -backend-config=password=${TF_PASSWORD} \n  -backend-config=lock_method=POST \n  -backend-config=unlock_method=DELETE \n  -backend-config=retry_wait_min=5<\/code><\/pre>\n
    The output is similar to this:<\/p>\n
    \n
      \"terraform<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    Test the Terraform script<\/h2>\n
    This sets the size of the VMs for my OpenStack flavors:<\/p>\n
    \n$ cat >> flavors.tf <\/code><\/pre>\n
    The settings for my external network are as follows:<\/p>\n
    \n$ cat >> external-network.tf <\/code><\/pre>\n
    Router settings look like this:<\/p>\n
    \n$ cat >> routers.tf <\/code><\/pre>\n
    Enter the following for images:<\/p>\n
    \n$ cat >> images.tf <\/code><\/pre>\n
    Here is a Demo tenant:<\/p>\n
    \n$ cat >> demo-project-user.tf <\/code><\/pre>\n
    When complete, you will have this file structure:<\/p>\n
    \n.\n\u251c\u2500\u2500 backend.tf\n\u251c\u2500\u2500 demo-project-user.tf\n\u251c\u2500\u2500 external-network.tf\n\u251c\u2500\u2500 flavors.tf\n\u251c\u2500\u2500 images.tf\n\u251c\u2500\u2500 provider.tf\n\u251c\u2500\u2500 routers.tf\n\u251c\u2500\u2500 terraform.tfvars\n\u2514\u2500\u2500 variables.tf<\/code><\/pre>\n
    Issue plan<\/h2>\n
    After the files are complete, you can create the plan files with the terraform plan<\/code> command:<\/p>\n
    \n$ terraform plan\nAcquiring state lock. This may take a few moments...\n\nTerraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:\n  + create\n\nTerraform will perform the following actions:\n\n  # openstack_compute_flavor_v2.large-flavor will be created\n  + resource \"openstack_compute_flavor_v2\" \"large-flavor\" {\n      + disk         = 0\n      + extra_specs  = (known after apply)\n      + flavor_id    = \"3\"\n      + id           = (known after apply)\n      + is_public    = true\n      + name         = \"large\"\n      + ram          = 16384\n      + region       = (known after apply)\n      + rx_tx_factor = 1\n      + vcpus        = 4\n    }\n\n[...]\n\nPlan: 10 to add,\nReleasing state lock. This may take a few moments...<\/code><\/pre>\n
    After all plan files have been created, apply them with the terraform apply<\/code> command:<\/p>\n
    \n$ terraform apply -auto-approve\nAcquiring state lock. This may take a few moments...\n[...]\nPlan: 10 to add, 0 to change, 0 to destroy.\nopenstack_compute_flavor_v2.large-flavor: Creating...\nopenstack_compute_flavor_v2.small-flavor: Creating...\nopenstack_identity_project_v3.demo-project: Creating...\nopenstack_networking_network_v2.external-network: Creating...\nopenstack_compute_flavor_v2.xlarge-flavor: Creating...\nopenstack_compute_flavor_v2.medium-flavor: Creating...\nopenstack_images_image_v2.cirros: Creating...\n[...]\nReleasing state lock. This may take a few moments...\n\nApply complete! Resources: 10 added, 0 changed, 0 destroyed.<\/code><\/pre>\n
    After applying the infrastructure, return to GitLab and navigate to your project. Look in Infrastructure<\/strong> \u2192 Terraform<\/strong> to confirm that the state homelab<\/code> has been created.<\/p>\n
    \n
      \"Gitlab<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    Destroy the state to test CI<\/h2>\n
    Now that you’ve created a state, try destroying the infrastructure so you can apply the CI pipeline later. Of course, this is purely for moving from Terraform CLI to a Pipeline. If you have an existing infrastructure, you can skip this step.<\/p>\n
    \n$ terraform destroy -auto-approve\nAcquiring state lock. This may take a few moments...\nopenstack_identity_project_v3.demo-project: Refreshing state... [id=5f86d4229003404998dfddc5b9f4aeb0]\nopenstack_networking_network_v2.external-network: Refreshing state... [id=012c10f3-8a51-4892-a688-aa9b7b43f03d]\n[...]\nPlan: 0 to add, 0 to change, 10 to destroy.\nopenstack_compute_flavor_v2.small-flavor: Destroying... [id=1]\nopenstack_compute_flavor_v2.xlarge-flavor: Destroying... [id=4]\nopenstack_networking_router_v2.external-router: Destroying... [id=73ece9e7-87d7-431d-ad6f-09736a02844d]\nopenstack_compute_flavor_v2.large-flavor: Destroying... [id=3]\nopenstack_identity_user_v3.demo-user: Destroying... [id=96b48752e999424e95bc690f577402ce]\n[...]\nDestroy complete! Resources: 10 destroyed.<\/code><\/pre>\n
    You now have a state everyone can use. You can provision using a centralized state. With the proper pipeline, you can automate common tasks.<\/p>\n
    Set up a GitLab runner<\/h2>\n
    Your OpenStack cluster isn’t public-facing, and the OpenStack API isn’t exposed. You must have a GitLab runner to run GitLab pipelines. GitLab runners are services or agents that run and perform tasks on the remote GitLab server.<\/p>\n
    On a computer on a different network, create a container for a GitLab runner:<\/p>\n
    \n$ docker volume create gitlab-runner-config\n\n$ docker run -d --name gitlab-runner --restart always \n  -v \/var\/run\/docker.sock:\/var\/run\/docker.sock \n  -v gitlab-runner-config:\/etc\/gitlab-runner \n  gitlab\/gitlab-runner:latest\n\n$ docker ps\nCONTAINER ID   IMAGE                           COMMAND                  CREATED         STATUS         PORTS                                       NAMES\n880e2ed289d3   gitlab\/gitlab-runner:latest     \"\/usr\/bin\/dumb-init \u2026\"   3 seconds ago   Up 2 seconds                                               gitlab-runner-test<\/code><\/pre>\n
    Now register it with your project in your GitLab project’s Settings<\/strong> \u2192 CI\/CD<\/strong> panel:<\/p>\n
    \n
      \"Gitlab<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    Scroll down to Runners<\/strong> \u2192 Collapse<\/strong>:<\/p>\n
    \n
      \"Gitlab<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    The GitLab runner registration token and URL are required. Disable the shared runner on the right side to ensure it works on the runner only. Run the gitlab-runner<\/code> container to register the runner:<\/p>\n
    \n$ docker exec -ti gitlab-runner \/usr\/bin\/gitlab-runner register\nRuntime platform                                    arch=amd64 os=linux pid=18 revision=6d480948 version=15.7.1\nRunning in system-mode.                            \n                                                   \nEnter the GitLab instance URL (for example, https:\/\/gitlab.com\/):\nhttps:\/\/gitlab.com\/\nEnter the registration token:\nGR1348941S1bVeb1os44ycqsdupRK\nEnter a description for the runner:\n[880e2ed289d3]: dockerhost\nEnter tags for the runner (comma-separated):\nhomelab\nEnter optional maintenance note for the runner:\n\nWARNING: Support for registration tokens and runner parameters in the 'register' command has been deprecated in GitLab Runner 15.6 and will be replaced with support for authentication tokens. For more information, see https:\/\/gitlab.com\/gitlab-org\/gitlab\/-\/issues\/380872 \nRegistering runner... succeeded                     runner=GR1348941S1bVeb1o\nEnter an executor: docker-ssh, shell, virtualbox, instance, kubernetes, custom, docker, parallels, ssh, docker+machine, docker-ssh+machine:\ndocker\nEnter the default Docker image (for example, ruby:2.7):\najscanlas\/homelab-runner:3.17\nRunner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!\n \nConfiguration (with the authentication token) was saved in \"\/etc\/gitlab-runner\/config.toml\" <\/code><\/pre>\n
    Upon success, your GitLab interface displays your runner as valid. It looks like this:<\/p>\n
    \n
      \"Specific<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    \n
    Explore the open source cloud<\/div>\n
    \n
    Free online course: Developing cloud-native applications with microservices<\/a><\/div>\n
    eBook: Modernize your IT with managed cloud services<\/a><\/div>\n
    Try for 60 days: Red Hat OpenShift Dedicated<\/a><\/div>\n
    Free online course: Containers, Kubernetes and Red Hat OpenShift<\/a><\/div>\n
    What is Kubernetes?<\/a><\/div>\n
    Understanding edge computing<\/a><\/div>\n
    Latest articles for IT architects<\/a><\/div>\n<\/p><\/div>\n<\/p><\/div>\n
    You can now use that runner to automate provisioning with a CI\/CD pipeline in GitLab.<\/p>\n
    Set up the GitLab pipeline<\/h2>\n
    Now you can set up a pipeline. Add a file named .gitlab-ci.yaml<\/code> in your repository to define your CI\/CD steps. Ignore the files you don’t need, like .terraform<\/code> directories and sensitive data like variable files.<\/p>\n
    Here’s my .gitignore<\/code> file:<\/p>\n
    \n$ cat .gitignore\n*.tfvars\n.terraform*<\/code><\/pre>\n
    Here are my CI pipeline entries in .gitlab-ci.yaml<\/code>:<\/p>\n
    \n$ cat .gitlab-ci.yaml\ndefault:\n  tags:\n    - homelab\n\nvariables:\n  TF_ROOT: ${CI_PROJECT_DIR}\n  TF_ADDRESS: ${CI_API_V4_URL}\/projects\/${CI_PROJECT_ID}\/terraform\/state\/homelab\n\ncache:\n  key: homelab\n  paths:\n    - ${TF_ROOT}\/.terraform*\n\nstages:\n  - prepare\n  - validate\n  - build\n  - deploy\n\nbefore_script:\n  - cd ${TF_ROOT}\n\ntf-init:\n  stage: prepare\n  script:\n    - terraform --version\n    - terraform init -backend-config=address=${BE_REMOTE_STATE_ADDRESS} -backend-config=lock_address=${BE_REMOTE_STATE_ADDRESS}\/lock -backend-config=unlock_address=${BE_REMOTE_STATE_ADDRESS}\/lock -backend-config=username=${BE_USERNAME} -backend-config=password=${BE_ACCESS_TOKEN} -backend-config=lock_method=POST -backend-config=unlock_method=DELETE -backend-config=retry_wait_min=5\n\ntf-validate:\n  stage: validate\n  dependencies:\n    - tf-init\n  variables:\n    TF_VAR_OS_AUTH_URL: ${OS_AUTH_URL}\n    TF_VAR_OS_PASSWORD: ${OS_PASSWORD}\n    TF_VAR_OS_REGION: ${OS_REGION}\n    TF_VAR_OS_TENANT: ${OS_TENANT}\n    TF_VAR_OS_USERNAME: ${OS_USERNAME}\n  script:\n    - terraform validate\n\ntf-build:\n  stage: build\n  dependencies:\n    - tf-validate\n  variables:\n    TF_VAR_OS_AUTH_URL: ${OS_AUTH_URL}\n    TF_VAR_OS_PASSWORD: ${OS_PASSWORD}\n    TF_VAR_OS_REGION: ${OS_REGION}\n    TF_VAR_OS_TENANT: ${OS_TENANT}\n    TF_VAR_OS_USERNAME: ${OS_USERNAME}\n  script:\n    - terraform plan -out \"planfile\"\n  artifacts:\n    paths:\n      - ${TF_ROOT}\/planfile\n\ntf-deploy:\n  stage: deploy\n  dependencies:\n    - tf-build\n  variables:\n    TF_VAR_OS_AUTH_URL: ${OS_AUTH_URL}\n    TF_VAR_OS_PASSWORD: ${OS_PASSWORD}\n    TF_VAR_OS_REGION: ${OS_REGION}\n    TF_VAR_OS_TENANT: ${OS_TENANT}\n    TF_VAR_OS_USERNAME: ${OS_USERNAME}\n  script:\n    - terraform apply -auto-approve \"planfile\"<\/code><\/pre>\n
    The process starts by declaring that every step and stage is under the homelab<\/code> tag, allowing your GitLab runner to run it.<\/p>\n
    \ndefault:\n  tags:\n    - homelab<\/code><\/pre>\n
    Next, the variables are set on the pipeline. The variables are only present when the pipeline is running:<\/p>\n
    \nvariables:\n  TF_ROOT: ${CI_PROJECT_DIR}\n  TF_ADDRESS: ${CI_API_V4_URL}\/projects\/${CI_PROJECT_ID}\/terraform\/state\/homelab<\/code><\/pre>\n
    There’s a cache that saves specific files and directories upon running from stage to stage:<\/p>\n
    \ncache:\n  key: homelab\n  paths:\n    - ${TF_ROOT}\/.terraform*<\/code><\/pre>\n
    These are the stages that the pipeline follows:<\/p>\n
    \nstages:\n  - prepare\n  - validate\n  - build\n  - deploy<\/code><\/pre>\n
    This declares what to do before any stages are run:<\/p>\n
    \nbefore_script:\n  - cd ${TF_ROOT}<\/code><\/pre>\n
    In the prepare<\/code> stage, the tf-init<\/code> initializes the Terraform scripts, gets the provider, and sets its backend to GitLab. Variables that aren’t declared yet are added as environment variables later.<\/p>\n
    \ntf-init:\n  stage: prepare\n  script:\n    - terraform --version\n    - terraform init -backend-config=address=${BE_REMOTE_STATE_ADDRESS} -backend-config=lock_address=${BE_REMOTE_STATE_ADDRESS}\/lock -backend-config=unlock_address=${BE_REMOTE_STATE_ADDRESS}\/lock -backend-config=username=${BE_USERNAME} -backend-config=password=${BE_ACCESS_TOKEN} -backend-config=lock_method=POST -backend-config=unlock_method=DELETE -backend-config=retry_wait_min=5<\/code><\/pre>\n
    In this part, the CI job tf-validate<\/code> and the stage validate<\/code> run Terraform to validate that the Terraform scripts are free of syntax errors. Variables not yet declared are added as environment variables later.<\/p>\n
    \ntf-validate:\n  stage: validate\n  dependencies:\n    - tf-init\n  variables:\n    TF_VAR_OS_AUTH_URL: ${OS_AUTH_URL}\n    TF_VAR_OS_PASSWORD: ${OS_PASSWORD}\n    TF_VAR_OS_REGION: ${OS_REGION}\n    TF_VAR_OS_TENANT: ${OS_TENANT}\n    TF_VAR_OS_USERNAME: ${OS_USERNAME}\n  script:\n    - terraform validate<\/code><\/pre>\n
    Next, the CI job tf-build<\/code> with the stage build<\/code> creates the plan file using terraform plan<\/code> and temporarily saves it using the artifacts<\/code> tag.<\/p>\n
    \ntf-build:\n  stage: build\n  dependencies:\n    - tf-validate\n  variables:\n    TF_VAR_OS_AUTH_URL: ${OS_AUTH_URL}\n    TF_VAR_OS_PASSWORD: ${OS_PASSWORD}\n    TF_VAR_OS_REGION: ${OS_REGION}\n    TF_VAR_OS_TENANT: ${OS_TENANT}\n    TF_VAR_OS_USERNAME: ${OS_USERNAME}\n  script:\n    - terraform plan -out \"planfile\"\n  artifacts:\n    paths:\n      - ${TF_ROOT}\/planfile<\/code><\/pre>\n
    In the next section, the CI job tf-deploy<\/code> with the stage deploy<\/code> applies the plan file.<\/p>\n
    \ntf-deploy:\n  stage: deploy\n  dependencies:\n    - tf-build\n  variables:\n    TF_VAR_OS_AUTH_URL: ${OS_AUTH_URL}\n    TF_VAR_OS_PASSWORD: ${OS_PASSWORD}\n    TF_VAR_OS_REGION: ${OS_REGION}\n    TF_VAR_OS_TENANT: ${OS_TENANT}\n    TF_VAR_OS_USERNAME: ${OS_USERNAME}\n  script:\n    - terraform apply -auto-approve \"planfile\"<\/code><\/pre>\n
    There are variables, so you must declare them in Settings<\/strong> \u2192 CI\/CD<\/strong> \u2192 Variables<\/strong> \u2192 Expand<\/strong>.<\/p>\n
    \n
      \"Gitlab<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    Add all the variables required:<\/p>\n
    \nBE_ACCESS_TOKEN => GitLab Access Token\nBE_REMOTE_STATE_ADDRESS => This was the rendered TF_ADDRESS variable\nBE_USERNAME => GitLab username\nOS_USERNAME => OpenStack Username\nOS_TENANT   => OpenStack tenant\nOS_PASSWORD => OpenStack User Password\nOS_AUTH_URL => Auth URL\nOS_REGION   => OpenStack Region<\/code><\/pre>\n
    So for this example, I used the following:<\/p>\n
    \nBE_ACCESS_TOKEN = \"wwwwwwwwwwwwwwwwwwwww\"\nBE_REMOTE_STATE_ADDRESS = https:\/\/gitlab.com\/api\/v4\/projects\/42580143\/terraform\/state\/homelab\nBE_USERNAME = \"ajohnsc\"\nOS_USERNAME = \"admin\"\nOS_TENANT   = \"admin\"\nOS_PASSWORD = \"YYYYYYYYYYYYYYYYYYYYYY\"\nOS_AUTH_URL = \"http:\/\/X.X.X.X:35357\/v3\"\nOS_REGION   = \"RegionOne\"<\/code><\/pre>\n
    And it is masked GitLab for its protection.<\/p>\n
    \n
      \"Gitlab<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    The last step is to push the new files to the repository:<\/p>\n
    \n$ git add .\n\n$ git commit -m \"First commit\"\n[main (root-commit) e78f701] First commit\n 10 files changed, 194 insertions(+)\n create mode 100644 .gitignore\n create mode 100644 .gitlab-ci.yml\n create mode 100644 backend.tf\n create mode 100644 demo-project-user.tf\n create mode 100644 external-network.tf\n create mode 100644 flavors.tf\n create mode 100644 images.tf\n create mode 100644 provider.tf\n create mode 100644 routers.tf\n create mode 100644 variables.tf\n\n$ git push\nEnumerating objects: 12, done.\nCounting objects: 100% (12\/12), done.\nDelta compression using up to 4 threads\nCompressing objects: 100% (10\/10), done.\nWriting objects: 100% (12\/12), 2.34 KiB | 479.00 KiB\/s, done.\nTotal 12 (delta 0), reused 0 (delta 0), pack-reused 0\nTo gitlab.com:testgroup2170\/testproject.git\n * [new branch]      main -> main<\/code><\/pre>\n
    View the results<\/h2>\n
    View your new pipelines in the CI\/CD<\/strong> section of GitLab.<\/p>\n
    \n
      \"Pipelines\"<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    On the OpenStack side, you can see the resources created by Terraform.<\/p>\n
    The networks:<\/p>\n
    \n
      \"Networks\"<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    The flavors:<\/p>\n
    \n
      \"Flavors\"<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    The images:<\/p>\n
    \n
      \"Images\"<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    The project:<\/p>\n
    \n
      \"Project\"<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    The user:<\/p>\n
    \n
      \"user\"<\/div>\n
    Image by: <\/span><\/p>\n
    (AJ Canlas, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
    Next steps<\/h2>\n
    Terraform has so much potential. Terraform and Ansible are great together. In my next article, I’ll demonstrate how Ansible can work with OpenStack<\/p>\n<\/div>\n
    \n
    Follow this tutorial to see how using GitLab can further enhance collaboration in your OpenStack cluster.<\/p>\n<\/div>\n
    \n
    \n
      \"diagram<\/div>\n
    Image by: <\/span><\/p>\n
    Opensource.com<\/p>\n<\/div>\n<\/article>\n<\/div>\n
    \n
    Containers<\/a><\/div>\n
    OpenStack<\/a><\/div>\n
    Git<\/a><\/div>\n
    GitLab<\/a><\/div>\n
    Cloud<\/a><\/div>\n
    CI\/CD<\/a><\/div>\n
    Automation<\/a><\/div>\n<\/p><\/div>\n
    What to read next<\/div>\n

    \n        \"Creative<\/a>This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.<\/div>\n
    \n
    \n
    Register<\/a> or Login<\/a> to post a comment.<\/div>\n<\/p><\/div>\n<\/section>\n
    Powered by WPeMatico<\/a><\/small><\/p>\n","protected":false},"excerpt":{"rendered":"
    Manage OpenStack using Terraform and GitLab ajscanlas Wed, 02\/15\/2023 – 03:00 One virtue of GitOps is Infrastructure as Code. It encourages collaboration by using a shared configuration and policy repository. Using GitLab can further enhance collaboration in your OpenStack cluster. GitLab CI can serve as your source control and orchestration hub for CI\/CD, and it […]<\/p>\n","protected":false},"author":1,"featured_media":71236,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[307],"tags":[],"class_list":["post-71235","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-open-source"],"_links":{"self":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/posts\/71235","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=71235"}],"version-history":[{"count":0,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/posts\/71235\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/media\/71236"}],"wp:attachment":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=71235"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=71235"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=71235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}