Another day in the life of a network engineer, except this time I need to play cloud engineer. Rather, I’m not doing cloud network engineering, but to deploy some network services, I first need to deploy some EC2 services.
As such, I figured that I’d share with you how I am using torero to share my Amazon AWS EC2 scripts with the team.
>_ the snowflake
First a little background. I work with a heavily engineering-focused product team. They like to test and use the products they’re making, but with that comes with creating tons of one off builds, one off demos, and one off proof of concepts. I’m not much a fan of “one off” because that means that I have to build a snowflake environment for everything. Instead, I now create torero services and, in this case, an opentofu plan to deploy a single instance of torero, and I can let them do what they want with it.
>_ the setup
We’re not working in a high load or production environment (yet), so I only have a single torero server setup in the cloud for each team. I’ve got two teams that I currently share with, so each team gets a server. One team doesn’t have access to their own EC2 instances, doesn’t know or want to know python, ansible, and opentofu, and doesn’t need daily automation.
The other team is the product team. They use it often, need quicker runs, but again, they don’t need to be running these scripts at night when I’m asleep, so no need for scaling or resiliency. If you’re working in an environment where scalable, resilient deployment is important, see my recent blog covering clustering in torero.
Here, I have deployed a t2.micro for team 1 and a t2.medium for team 2. My only ports that I need to open are ssh (for me) and 50051 for torero. This is configurable, and one might argue that I could put both torero instances on the same server, and they’d be right. I may even migrate them one day, but for now, let’s say it’s because I want to keep the two teams from stepping on each other’s toes.
Then, all I need to do is provide each end user with a user/pass that I setup for them, and a config file.
torero create user peter
Enter your password: peterIsTheBestBoss
Make sure your password is long enough to convey some deeper meaning that only they would get. It’s just good password management practice. Unfortunately, they can and probably should change the password once they first login. That’s okay. The important work is done.
Then, I provide a quick torero.conf file for them, the download link, and tell them to save this to ~/.torero/torero.conf
[application] mode = client [client] host = 1.2.3.4 #your torero server IP goes here port = 50051 use_tls = false
Note: this is NOT a secure environment. I highly recommend setting up secure environments for anyone that will be using important or secure information (like AWS keys with team 2).
On the server side, I’ve configured this server as such:
[application] mode = server [log] server_dir = /home/ec2-user/torero.log [secrets] encrypt_key_file = /home/ec2-user/priv.key [server] listen_address = 0.0.0.0 port = 50051 use_tls = false
Note: you do need to setup a secrets key on the servers, so see the Secrets Management documentation to setup your priv.key.
>_ the script
Now let’s look at the repo. I’ve made it publicly available, so you can copy and use it yourself should you want to.
git clone https://github.com/torerodev/singlehost-ec2-torero
Simple instructions are in the README.md to deploy using opentofu. Essentially you run an opentofu plan and set the AWS key or profile that you want to use, then set the SSH key that you want to use, and you’re off. There’s plenty of variability in there, so look at the variables if you want to change anything. As an example, it deploys a t2.micro by default.
cd singlehost-ec2-torero opentofu init opentofu apply -auto-approve\ --var instance-key-name=name_of_a_key_in_ec2\ --var aws-access-key=your_aws_key\ --var aws-secret-key=your_aws_secret
That said, this is torero, so if you want to deploy this, just set up a service in your local torero environment and run it! I’ve added a torero-service.json file to the repo, but here it is as well.
decorators: - name: ec2-keys schema: $id: root $schema: http://json-schema.org/draft-07/schema# additionalProperties: false properties: aws-access-key: type: string aws-secret-key: type: string instance-key-name: type: string required: - aws-access-key - aws-secret-key - instance-key-name type: object repositories: - name: torero-single-repo description: "" url: https://github.com/torerodev/singlehost-ec2-torero.git reference: "" tags: [] private-key-name: "" services: - name: torero-in-EC2 type: opentofu-plan description: Build a single node in EC2 working-directory: "" repository: torero-single-repo decorator: ec2-keys
This one is a bit fancy. I’ve added some decorators to make sure people put in the correct information to run the service. Nice guardrails.
Anyway, now we can run this in torero and deploy a new torero instance!
torero db import torero-service.json torero run opentofu-plan torero-in-EC2\ --set aws-access-key=some_key\ --set aws-secret-key=some_secret\ --set instance-key-name=mykey-name-in-ec2\ --state-out=./tf.json
Note: opentofu will create a state file. We’re saving that to tf.json, and that’s needed to destroy this instance. You’ll want to make sure the users understand that.
Then, should you want to revert or shutdown, just do a destroy:
torero run opentofu-plan destroy torero-in-EC2\ --set aws-access-key=some_key\ --set aws-secret-key=some_secret\ --set instance-key-name=mykey-name-in-ec2\ --state @./tf.json
>_ the life
Sharing scripts is now becoming a job of scripting and not one of dealing with how to share it.
I’m a network guy, and I can easily create a service with a few commands. Users quickly pick up the user side of things, and I look like a rockstar with all the scripts that I can share. Updating scripts is now a matter of what I update on my laptop and push to git. Heck, in the time of writing this, I pushed 2-3 new changes that my users won’t need to know about!
Once you adopt the torero mindset, scripting becomes fun again!
Learn more about the new torero 1.1 release here.
Wyatt Sullivan
Technical Marketing Engineer ‐ Itential
Wyatt Sullivan, CCIE 18027, has been pushing packets for nearly 25 years. Yes, he’s old. He has accidentally taken down an entire datacenter, bricked network devices, created a loop in a network that caused a 120 minute brownout well outside of the local domain, cleared an entire VTP domain by adding a new device, and once requested a raise. Due to sheer laziness, his first automations were designed in 2000s with excel spreadsheets and bash scripts. By the time he was a Chief Network Architect, he was building scalable web portals for the ops teams to locate devices on the network because he was sick of finding those devices for them. Once he realized he was no longer valuable to real companies, he moved into the vendor space where he has been shilling, automating, and helping network engineers blame other departments for the past decade.
