🚀Getting Started
Last updated
Last updated
We use Gitpod to develop the platform. You can have a complete development environment to test all the components and features with one click using the following button.
Gitpod is free for 50 hours every month, so you dont have to worry for testing the application.
Running Terrakube in Gitpod is like running the platform in any Kubernetes distribution in Azure, Aws or GCP, so you will be able to use all the features available with one single click without installing any software in your computer and the environment should be ready in only 1 or 2 minute.
Terrakube API uses an in memory database, it will be deleted and preloaded with default information in every startup.
A file called GITPOD.md will have the information for the entire workspace
The configuration is generated dynamically using the following bash script. This is executed by Gitpod in the environment startup process.
If for some reason we need to execute the script again, it needs to be executed form the /workspace/terrakube folder
The development environment will have the following information:
Groups |
---|
TERRAKUBE_ADMIN |
TERRAKUBE_DEVELOPERS |
AZURE_DEVELOPERS |
AWS_DEVELOPERS |
GCP_DEVELOPERS |
User | Password | Member Of |
---|---|---|
admin | TERRAKUBE_ADMIN, TERRAKUBE_DEVELOPERS | |
aws | AWS_DEVELOPERS | |
azure | AZURE_DEVELOPERS | |
gcp | GCP_DEVELOPERS |
To run all the Terrakube components run the following task:
After a couple of seconds all the components will be running, you can start/stop/restart any component as needed.
After the application startup is completed, we can login to the development environment, to get the URL you can execute the following command:
The Terrakube login will look like this example:
The Gitpod environment is using an OpenLDAP tha is connected to a Dex using the LDAP connector. The OpenLDAP configuration(users and groups) can be found in the following file:
The Dex configuration file is generated dynamically and will be available in the following file:
The template that is used to generate the Dex configuration file can be found in this path:
Dex login page should look like this example:
The development environment will be preloaded with 4 organizations(azure, gcp, aws and simple), this information is loaded inside the API startup and the scripts to load the information can be found in the following xml files
Depending of the selected organization and user you will see different information available.
Each organization is preloaded with some modules that can be found in Github like the following:
Each organization is preloaded with the following templates to run Terrakube jobs:
For more information of how to use templates please refer to the following repository
All the organization have different empty workspaces, the Simple organization can be used for testing because the workspace is using a basic terraform file with the following resources:
null_resource
time_sleep
Other workspaces can be created but they will be deleted on each restart unless are added inside the initialization scripts:
Gitpod has the thunder-client installed to easily test the API without using the UI.
All the environment variables for the collection are generated on each Gitpod workspace startup The environment variables template can be found in the following directory:
To authenticate the thunder client you can use Dex Device Code Authentication using the following request
The response should look like the following and you can use the verification_uri_complete to finish the device authentication.
Once the Dex device code authentication is completed you can use the following request to get the access token.
Now you can call any method available in the API without the UI
Terraform login protocol can be tested using the thunder-client collection:
The response should look similar to the following:
There is one example of terraform module protocol inside the thunder-client collection that you can be used for testing purposes executing the following two request.
The response should look like the following:
Getting versions for the module
Getting zip file for the module
The specification can be obtained using the following request: