Escaping Click Ops: Why Manual Infrastructure Changes No Longer Scale
We’ve all been there. A new application needs to be delivered, or a new requirement has emerged, requiring us to change the NetScaler. We can’t make changes to the NetScaler during the day while it is in production. Some companies are prepared with dev, test, and production environments at the ready. But even after all the tests, making changes to the production environment can’t be done during the day. And how do I ensure that the settings we came up with in the development environment and tested in the testing environment are what is set when I take it into production? And let’s not get started on the time it takes away when you must deploy the changes after 9 PM, so it doesn’t impact anyone working. And what if even after all the testing, we find a problem? How do we roll back quickly? We can grab a quick difference in the diagnostics section and start manually entering the reversion commands from the CLI, or take the chance of rolling back a snapshot or restoring from backup. Isn’t there an easier way to accomplish all these clicks?
Embracing Automation with Infrastructure as Code (IaC)
This is where automation with Infrastructure as Code (IaC) comes in. By following similar practices that developers use to code, test, implement, and, if needed, roll back application changes, we can make similar changes in the infrastructure by utilizing a set of files that have all the current configuration settings and those we are trying to make. Then, when we need to make changes, we can simply modify these files to add or remove the settings in the environment and then apply the changes at the proper time. We can use the same configuration files with variables for the settings that change between dev, test, and production. Things like IP addresses, virtual server names, etc. This allows the modification to be made, then apply the setting in the dev environment by specifying the dev variables file. Once the development is complete, the new settings are applied using the same files, but with the testing variables. And, when testing is completed, the changes can be made by using the same settings files and the production variables. In this manner, we can be sure that every setting matches. Utilizing change control functions like Git allows us to quickly roll back the settings and then apply the files to return us to the previous working environment. Plus, we can make the setting changes during the day, and then in the evening, simply run a command to apply the changes instead of clicking our way through the changes while everyone else is spending time with their families.
Other advantages to using IaC include
- Eliminate the configuration drift across environments
- All changes are added or removed in the same way
- Scalability
- You can spin up identical environments and even more resources quickly and easily
- Collaboration
- By using change control and code files for your infrastructure, multiple coworkers can make modifications at the same time.
- Changes can be reviewed by multiple users, enabling error correction before implementation.
- Auditability
- It is easy to see who made what changes and when.
The Challenge: Turning Existing Infrastructure into Code
This plan seems very nice if we are starting from scratch, and we can ensure that all changes are implemented following these practices. But what about existing infrastructure? There is a lot of technical debt and existing efforts to build the environments that are running in our infrastructure today. And it can be very difficult to change your “click ops” setups or even CLI commands into useful IaC files. Until now.
Introducing NSCONF2IAC: Automating NetScaler to IaC Conversion
NetScaler developed a new tool called NSCONF2IAC. This tool is a series of Python scripts that can either take an ns.conf file directly or connect to an appliance and collect the ns.conf file, then convert the settings to a Terraform file or Ansible playbook. The tool works by initially converting the configuration into a Nitrograph JSON file and then either converting the file into Terraform or Ansible format.
Step-by-Step: From ns.conf to Terraform or Ansible
Let’s look at how that would go.
Running the NSCONF2IAC tool for a Terraform file.
- Install the prerequisite Python, Terraform, or Ansible requirements.
- Fork and clone the NetScaler NSCONF2IAC tool to obtain the Python scripts
- Execute the Python code by running:
python3 nsconf2iac.py [-h] -i INPUT -o OUTPUT [-v] -t TARGET_ADC -u USERNAME_ADC -p PASSWORD_ADC -type {terraform, ansible} [-a ADM_IP]
Notes:
Required arguments:
-f FILE, –file FILE
Input inventory file containing configuration parameters.
If specified, the following fields must be present in the file:
target-adc – IP address of NetScaler
username – Username of NetScaler ADC/ADM(In case of ADM proxy)
output – Output file name
type – Type of output (terraform or ansible)
adm_ip – IP address of the ADM proxy server
adm_id – ID of the ADM proxy server
adm_secret – Secret of the ADM proxy server
The following are optional in the file:
password – Password of NetScaler ADC/ADM(In case of ADM proxy)
input – Path to ns.conf file
Note: help and verbose can be provided via CLI if needed.
If –file is not specified, the following CLI arguments are required:
-t TARGET_ADC, –target-adc TARGET_ADC
IP address of NetScaler
-u USERNAME, –username USERNAME
Username of NetScaler ADC/ADM(In case of ADM proxy)
-o OUTPUT, –output OUTPUT
Output file name
-type {terraform, ansible}, –type {terraform, ansible}
Type of output (terraform or ansible)
-a ADM_IP, –adm-ip
IP address of the ADM proxy server
Optional arguments:
-p PASSWORD, –password PASSWORD
Password of NetScaler ADC/ADM (In case of ADM proxy).
If not specified, it will be taken from the environment
variable NS_PASSWORD or prompted.
-i INPUT, –input INPUT
Input ns.conf file. Leave this empty to fetch ns.conf from
the specified NetScaler.
-v, –verbose Enable verbose output
-h, –help Show this help message and exit
Examples:
To generate a Terraform script:
python3 nsconf2iac.py -i ns.conf -o main.tf -t 10.10.10.10 -u nsroot -p demopass -type terraform
To generate an Ansible Playbook:
python3 nsconf2iac.py -i ns.conf -o main.yaml -t 10.10.10.10 -u nsroot -p demopass -type ansible
To generate using an input file
python3 nsconf2iac.py -f inventory.ini
To generate using an ADM Proxy
python3 nsconf2iac.py -i ns.conf -o main.tf -t 10.10.10.10 -u nsroot -p demopass -a 1.1.1.1 -type terraform
Once you have generated the file, you are going to need to open it with your favorite code editor and either grab the relevant portions of the generated file or remove the baseline configuration items that are listed. The generated file will contain many of the default settings that are not required to be in your usable file. While this is not ideal, it will save you a lot of configuration time. Here’s an example of a generated Terraform script.
While this script will not give a usable file, it will display the commands as they would appear to configure a new NetScaler to match your settings. This saves an immense amount of time putting in each line of existing code.
Bringing It All Together
Modern infrastructure demands more than manual effort—it demands speed, repeatability, and confidence. NSCONF2IAC bridges the gap between legacy configurations and the modern IaC world, giving you a head start toward true automation without starting from scratch. Whether you’re maintaining a single NetScaler or managing complex multi-environment deployments, these scripts can shave hours—or even days—off your configuration workflows.
Think of it as your on-ramp to Infrastructure as Code. Instead of endless late-night “click ops” sessions, you can version, test, and deploy changes in minutes, not hours.
Ready to Modernize Your NetScaler Infrastructure?
If you’re ready to take control of your NetScaler configurations and modernize your operations, try out the NSCONF2IAC scripts today and see the difference firsthand.
And if you’d prefer expert guidance to accelerate your transition, Ferroque Systems can help. Our team has deep experience automating Citrix and NetScaler environments, building scalable Terraform and Ansible frameworks, and helping organizations move from manual operations to fully automated IaC-driven deployments.
Ready to get started with nsconf2iac? Contact the NetScaler team at Netscaler-automationtoolkit@cloud.com to begin transforming your configurations into code—and your infrastructure into something you can deploy, replicate, and trust with confidence.
Watch the Live Demo:
Looking for more helpful resources? Check out the links below:
https://www.youtube.com/@FerroqueSystems
https://www.ferroquesystems.com/resources/netscaler-adc/
https://github.com/netscaler/nsconf2iac
https://github.com/netscaler/automation-toolkit
-
Richard Faulkner
Rich is a veteran architect and enthusiastic supporter of EUC, with over two decades of experience. He excels in sharing his technology expertise and aiding IT staff in optimizing digital workspaces. Rich has lived across the US and served as a Nuclear Engineer in the US Navy on submarines before transitioning to an IT career.