-
Notifications
You must be signed in to change notification settings - Fork 1
Tool Manager Configuration
Ready to get into the nitty-gritty? You've come to the right place. If you want a softer introduction to the DevXP workflow, please visit the Example Workflow page of the wiki.
This section will discuss how to use DevXP to set up your cloud services with Terraform, but for more background information about what Terraform is and why you should use it, please read the Terraform page of the wiki.
It is always useful to start by identifying your goal. Perhaps you are like Dave and have been tasked to set up [insert Dave's requirements] on top of your already long list of responsibilities. Perhaps you:
- are investigating what resources are available to you through each provider and what some of the configuration parameters mean.
- want to get an understanding of how to write a complete Terraform configuration file.
- were overwhelmed by all the options that were available to you and are looking for a simpler set of configuration options that you can digest.
You may have a different goal in mind, but regardless, you probably want to end up with a set of cloud services configured and deployed. If you are just here to learn, feel free to keep exploring the wiki and clicking around in the tool manager to see what this is all about.
- Determine what cloud resources you would like to configure to achieve your end goal. You can find information about supported resources in the resources section of the Terraform page in this wiki.
- Choose a provider, and create an account with them. Currently DevXP only supports three major providers as discussed in the linked Terraform page of the wiki.
- Download Terraform
- Familiarize yourself with the core workflow commands. Run
terraform -help
to get a list of commands. The main commands are init, plan, apply, and destroy. - Configure credentials so that Terraform knows what account to deploy the resources to (and so the cloud service provider knows who to bill!). We recommend the easy option of installing your provider's (aws or gcloud) cli tool, and authenticating with it. (For aws run
aws configure
and for gcloud rungcloud auth login
). However there are multiple ways to do this, so long as you are careful not to let your credentials leak into your repository or any other public files. - Now you are ready to create a terraform configuration file using DevXP!
This section describes the required configuration parameters associated with each supported resource for terraform. To learn more about the resources themselves, please visit the supported resources section in the Terraform page of the wiki.
-
Azure (Coming Soon!)
Begin by selecting a provider. Presently only Amazon (AWS) and Google (GCP) are supported.
The following settings affect all resources, but are currently only available when Amazon is the selected provider.
- Dictates whether or not to:
- put all the configured resources into their own VPC,
- setup a subnet, and
- give them IAM permissions to access each other.
- The secure option will force IAM users to be created for some resources that need one. It will then automatically attach those IAM users to any EC2 instances so that, by default, those EC2 instances will have access to the other resources with no further authentication needed.
- Please note that there are additional costs associated with setting up a VPC for your resources, but it is considered best practice for the security of your projects and to follow the principle of least privilege.
- Opens port 22 on the network gateway, which closes all ports in and out of the VPC by default. Enabling this option allows the user to set up an SSH connection with the configured resources.
- If you do not need this functionality, it is more secure to leave it unchecked.
- Opens ports 443 and 80 inbound to the VPC via the network gateway.
- Suppose you decide to run a web server, this option allows outside entities to make requests to it.
- If you do not need this functionality, it is more secure to leave it unchecked.
- Opens ports 443 and 80 outbound from the VPC via the network gateway.
- This means your resources can access the internet.
- If you do not need this functionality, it is more secure to leave it unchecked.
- Creates a load balancer instance.
- This allows requests to go to a single service (that is, the load balancer) where they are then distributed across your compute instances.
- This can help optimize your usage and cut down on costs. During times of high request rates, more resources can be provisioned, and during times of low request rates, resources can be shut down.
- Please note that there are additional costs associated with enabling network load balancing, and it may not be necessary unless your system receives a high rate of requests.
- This will be used to identify the resource in the future.
- By default, an ID is generated following this template: ResourceName-[random allowable characters]
- If the checkbox is ticked, you may enter a more recognizable ID.
- NOTE: Storage resources must be globally unique (S3, Glacier, GCP, Blobs & Containers), so it is recommended that you leave the randomly generated ID, or make your ID sufficiently unique.
- Allowable Values: Letters and hyphens. No other special characters, numbers, or spaces are allowed.
- SPECIAL NOTE: As of right now, no special validation is done for storage resources, so it is the user's responsibility to make sure that the resource ID meets the criteria given by the respective provider (see the links in the point above).
- The number of resources with these settings. Note that the instance name for each instance will be the same with the addition of a unique suffix.
- (e.g. If the resource name was "Bob" and the number of resources was 2, they would be named "Bob-a" and Bob-b").
- Allowable Values: Positive integers.
- Creates an IAM user with permissions for the resource in question.
- To access/modify this resource programmatically, through code, or from another resource, you must use an IAM user with the right permissions.
- If this is disabled, the only way to access/modify the resource is manually (e.g. through the console).
- This option creates an access key that can be downloaded and used to access the resource through tools such as a CI/CD pipeline.
- Allowable Values: Checked (True) or Unchecked (False)
- Common Resource Settings
- OS: This is the operating system your instance will run on.
- Allowable Values: Dropdown (Amazon Linux 2, Ubuntu Server, Windows Server, MacOS Monterey, etc.)
- Hardware: The computational power of your instance. This controls the number of CPUs and the amount of RAM your instance has access to.
- Allowable Values: Dropdown (micro, small, medium, etc.)
- To learn more about the hardware, visit this page. DevXP currently supports subsets of the t2 (general purpose), c3 (compute optimized), d2 (storage optimized), and r3 (memory optimized) hardware types.
- Note: When MacOS is the chosen OS, there is only the Mac Hardware option. See details about it here, and be aware that there is a special pricing plan that charges a minimum of 24 hours usage.
- Common Resource Settings
-
Runtime: This sets up an environment for the programming language your function is written in. For more information, visit this page
- Allowable Values: Dropdown (NodeJS 14, Java 8, Python 3.9, etc.)
- Keep Warm: In order to maintain a responsive function, you may wish to periodically call the function to keep it active. This is called keeping it warm.
- Lambda functions have a 3-stage lifecycle including:
- Init: The first time your function receives a request, your function's runtime environment is provisioned.
- Invoke: After being initiated, your function is ready to respond to incoming requests.
- Shutdown: After a certain length of inactivity, your function is shutdown.
- Enabling the Keep Warm setting sets up a CloudWatch timer through Terraform. It will result in your function being called every minute.
- This presents a trade off: Sending empty requests with the use of a timer vs. potentially suffering from long response times when a function has been shutdown.
- Allowable Values: Checked (True) or Unchecked (False)
- Lambda functions have a 3-stage lifecycle including:
- Filename: A relative path (beginning in the root of your repository) to the source file containing the function. Note that you must include the file extension (e.g. "./src/file.js" or "src/file.js" without quotation marks).
- Allowable Values: Text representing a filepath.
- Exported Handler: The name of the exported function within the file given by Filename (e.g. main).
- Allowable Values: Valid function name according to the programming language used.
- Common Resource Settings
- Attribute Name: This is the name of an attribute within the database.
- Allowable Values: Text (lowercase or uppercase letters). No special characters, numbers, or spaces are allowed.
- Type: This determines the datatype of the attribute.
- Allowable Values: Dropdown (String, Number, Binary)
- Common Resource Settings
- OS: This is the operating system your instance will run on.
- Allowable Values: Dropdown (Ubuntu 20.04, CentOS 8, Fedora 35, Windows Server, etc.)
- Hardware: The computational power of your instance. This controls the number of virtual CPUs and the amount of memory (RAM) your instance has access to.
- Allowable Values: Dropdown (micro, standard, large, etc.)
- To learn more about the hardware, visit this page. DevXP currently supports f1-micro (micro), n1-standard-1 (standard), e2-standard-2 (large), and e2-standard-8 (extra large).
- Common Resource Settings
-
Runtime: This sets up an environment for the programming language your function is written in.
- Allowable Values: Dropdown (NodeJS 16, Java 17, Python 3.9, etc.)
- HTTP: Whether this function is triggered by HTTP requests.
- Allowable Values: Checked (True) or Unchecked (False)
- Source Directory: A relative path (beginning in the root of your repository) to the source directory containing the file with the function.
- Allowable Values: Text representing a directory path.
- Exported Entry Point: The name of the exported function within the source file (e.g. main).
- Allowable Values: Valid function name according to the programming language used.
- Memory: Maximum memory (RAM) given to the function in MegaBytes (MB).
- Allowable Values: Positive integers.
- Common Resource Settings
- Docker image: The URL for your container image.
- Learn more about Docker here.
- Variable Name: A variable name that should be set at runtime, such as a secret. Your Docker container is likely to require certain variables with sensitive information that should not be in your repository. This setting allows you to indicate to Terraform which variables you are going to set yourself.
- You can create a terraform.tfvars file or manually enter the variable value when prompted while running Terraform apply.
- Allowable Values: Uppercase and lowercase letters as well as underscores.
Support for Microsoft Azure features is on its way!
DevXP - Empowering developers by making DevOps simple.