Citrix ADC
ProviderCitrix has developed a custom Terraform provider for automating Citrix ADC deployments and configurations. Using Terraform, you can custom configure your ADCs for different use-cases such as Load Balancing, SSL, Content Switching, GSLB, WAF etc.
Learn more about Citrix ADC Automation here
?For deploying Citrix ADC in Public Cloud - AWS and Azure, check out cloud scripts in github repo terraform-cloud-scripts.
✉️ For any immediate issues or help , reach out to us at [email protected] !
remote-exec
for one-time tasksTerraform is an open-source infrastructure as code software tool that provides a consistent CLI workflow to manage hundreds of cloud services.Terraform codifies cloud APIs into declarative configuration files. Terraform can be used to deploy and configure ADC. Configuring Citrix ADC through Terraform provides multiple benefits.
citrixadc
folder - Contains all the ADC resources library that we support through Terraform. These resource libraries will internally call NITRO APIS to configure target ADC.examples
folder - Contain the examples for users to use various ADC resources e.g simple_lb folder contains the resources.tf that illustrates how citrixadc_lbvserver resource can be used to create a Load Balancing vserver on target ADC. Similarly , different folders contains examples on defining different resources. Users are expected to review these examples and define their desired ADC configurations.docs
folder` - https://github.com/citrix/terraform-provider-citrixadc/tree/master/docs/resources - contains the documentation of all resources confgirations supported through Terraform. Refer this to understand the different arguments, values that a particular resource takes.provider.tf
contains the information on target ADC where you want to apply configuration.
provider "citrixadc" {
username = "${var.ns_user}" # You can optionally use `NS_LOGIN` environment variables.
password = "${var.ns_password}" # You can optionally use `NS_PASSWORD` environment variables.
endpoint = "http://10.71.136.250/" # You can optionally use `NS_URL` environment variables.
}
We can use a https
URL and accept the untrusted authority certificate on the Citrix ADC by specifying insecure_skip_verify = true
To use https
without the need to set insecure_skip_verify = true
follow this guide on
how to replace the default TLS certificate with one from a trusted Certifcate Authority.
Use of https
is preferred. Using http
will result in all provider configuration variables as well as resource variables
to be transmitted in cleartext. Anyone observing the HTTP data stream will be able to parse sensitive values such as the provider password.
Avoid storing provider credentials in the local state by using a backend that supports encryption. The hasicorp vault provider is also recommended for storing sensitive data.
You can also use environment variables as stated in the comments above.
The following arguments are supported.
username
- This is the user name to access to Citrix ADC. Defaults to nsroot
unless environment variable NS_LOGIN
has been setpassword
- This is the password to access to Citrix ADC. Defaults to nsroot
unless environment variable NS_PASSWORD
has been setendpoint
- (Required) Nitro API endpoint in the form http://<NS_IP>/
or http://<NS_IP>:<PORT>/
. Can be specified in environment variable NS_URL
insecure_skip_verify
- (Optional, true/false) Whether to accept the untrusted certificate on the Citrix ADC when the Citrix ADC endpoint is https
proxied_ns
- (Optional, NSIP) The target Citrix ADC NSIP for MAS proxied calls. When this option is defined, username
, password
and endpoint
must refer to the MAS proxy.The username, password and endpoint can be provided in environment variables NS_LOGIN
, NS_PASSWORD
and NS_URL
.
Resources.tf contains the desired state of the resources that you want on target ADC. E.g. For creating a Load Balancing vserver in ADC following resource.tf contains the desired configs of lbvserver
citrixadc_lbvserver
resource "citrixadc_lbvserver" "foo" {
name = "sample_lb"
ipv46 = "10.71.136.150"
port = 443
servicetype = "SSL"
lbmethod = "ROUNDROBIN"
persistencetype = "COOKIEINSERT"
sslcertkey = "${citrixadc_sslcertkey.foo.certkey}"
sslprofile = "ns_default_ssl_profile_secure_frontend"
}
In order to understand the arguments, possible values, and other arguments available for a given resource, refer the NITRO API documentation https://developer-docs.citrix.com/projects/netscaler-nitro-api/en/12.0/configuration/load-balancing/lbvserver/lbvserver/ and the Terraform documentation such as https://github.com/citrix/terraform-provider-citrixadc/blob/master/docs/resources/lbvserver.md .
the attribute
state
is not synced with the remote object. If the state of the lb vserver is out of sync with the terraform configuration you will need to manually taint the resource and apply the configuration again.
The subfolders in the example folder contains examples of different ADC configurations through terraform. Refer to simple_lb example to understand below structure and usage.
resources.tf
describes the actual NetScaler config objects to be created. The attributes of these resources are either hard coded or looked up from input variables in terraform.tfvars
variables.tf
describes the input variables to the terraform config. These can have defaultsprovider.tf
is used to specify the username, password and endpoint of the NetScaler. Alternatively, you can set the NS_URL, NS_LOGIN and NS_PASSWORD environment variables.terraform.tfvars
has the variable inputs specified in variables.tf
terraform.tfvars
and provider.tf
to suit your own NetScaler deployment.terraform plan
and terraform apply
to configure the NetScaler.Modify the set of backend services and use terraform plan
and terraform apply
to verify the changes
The provider will not commit the config changes to Citrix ADC's persistent store. To do this, run the shell script ns_commit.sh
:
export NS_URL=http://<host>:<port>/
export NS_LOGIN=nsroot
export NS_PASSWORD=nsroot
./ns_commit.sh
To ensure that the config is saved on every run, we can use something like terraform apply && ns_commit.sh
List of Use-Cases supported in ADC can be found in here https://registry.terraform.io/providers/citrix/citrixadc/latest/docs .
remote-exec
for one-time tasksTerraform is useful for maintaining desired state for a set of resources. It is less useful for tasks such as network configuration which don't change. Network configuration is like using a provisioner inside Terraform. The directory examples/remote-exec
show examples of how Terraform can use ssh to accomplish these one-time tasks.
Try out our Hands on Lab to experience whats it like using Terraform for ADC.
First step to using Terraform for ADC is to install Terraform CLI. Refer the Hashicorp documentation for installing Terraform CLI for your own environment.
Refer the Navigating our repository section
Follow the article on Getting started with Terraform on NetScaler to get your first configuration
To write the Terraform resources for Citrix ADC, refer the following links NITRO API documentation or terraform registry documentation.
Here is the Terraform Template that you follow to configure SSL Offloading.
Refer the commiting changes section
You want to see the current state of ADC entities in Terraform
If you want to override the ADC configuration with the configs you have in Terraform resource file then
Update your terraform state file to reflect the current/true state of ADC
Learn how to import existing NetScaler configurations into Terraform resources here
Refer our terraform cloud scripts for AWS and demo video
TBD
Our Consul-Terraform-Sync integration allows users to automatically create, update and delete Service groups in Citrix ADC that are synced with the Consul Terraform Sync framework.
Integrate ADC and configure it faciliate Blue-Green deployment using Terraform.Check out the solution