KSAOUG organized the Bi-Weekly Virtual Meetup With Sean Scott on the 13th of August, 2022. We have received very good questions from the attendees, and we would like to share the questions and the responses from Sean Scott.
Imran Khan: I believe we can give any name for variables irrespective of the block we defined within Curley basis of variable.tf…
Sean Scott: Yes Imran, excellent question! You’re right, variables can have any name (as long as they don’t break Terraform’s rules for variable naming). I named my variables to match the parameters used by the resources. I find it’s clearer that way since I’m not trying to remember what variables are assigned where. For others, it may be confusing to have two different thing things with the same name.
Ultimately, do what makes the most sense for you and/or your team!
Imran Khan: we are now into preparing DG FAR sync instances on azure cloud which will be a copy of our production primary databases hosted on prem .. what will be your suggestion on using terraform to avoid variuos manual steps ?
Sean Scott: I’m working on something similar for a customer right now! I obviously can’t share IP, but if you like, please send me an email at [email protected] with your questions and I’ll do my best to answer what I can. But, generally, my advice is:
- Use Terraform to manage as much as possible.
- Abstract or generalize your project by using variables to handle and pass information.
- Break things into discrete operations that parallel the high level tasks you’re trying to perform.
For example, some very general steps for setting up Data Guard Far Sync:
- Create a Standby database
- Create a Far Sync instance
- Set up the DG Broker
- Configure the Far Sync instance
- Restore the primary database to the standby
Creating a standby and creating a Far Sync database are very similar operations. Instead of having individual Terraform operations for each, can you write a resource definition that creates a database using some input variables? Then, based on whether it’s a Far Sync or Standby, create the proper resource?
You might find some inspiration here:
https://github.com/oraclesean/docker-oracle/tree/master/labs/farsync
That builds out Data Guard Far Sync in docker-compose. It may have insights you can apply to your Terraform project, too!
Vishweshwara Rao: could you please explain me what are the benefits of using Terraform ?
Nagaraj: As we already have OCI console access, Why we need to use terraform to create ADB? In simple three or four clicks I can create an ADB. What extra benefits (in addition to console access) we have with terraform?
Sean Scott: Both great questions, with similar answers. I’ve put together a bit of a combined response here.
There are many reasons to adopt Infrastructure as Code tools (including Terraform). For me, the top benefits are:
- Reliability: If I let Terraform (or any automation tool) do something for me, I’m eliminating the possibility of human error. Things that introduce human error:
- The length and complexity of the procedure.
- My familiarity with the procedure: Did I write it or did someone else? Has it been a long time since I last did it?
- The more pressure you’re under to get something done, the more likely you are to be distracted, miss or skip a step, and overlook warning signs and errors.
- More than one person actively contributing to a task creates misunderstanding and conflict.
- Confidence: If I build a test system with automation, I should be able to build a production system the same way (and vice-versa). The scale may be different (more cores, more storage) but the function will be the same. So, when I need to test something I’m more confident the two systems are comparable, and that changes in test produce the same results in production.
Simple things may seem better to do manually, but is that really true? Take building an Autonomous Database in OCI. It’s a few clicks and well documented. In a real enterprise will you ever have just one ADB? Will it exist in a vacuum, without a VCN, some storage, and other resources? Probably not. The ADB is one piece of a larger landscape.
If you have automation for building a VCN, some for building storage, and another for building compute, you can assemble those building blocks to make a whole environment. Does it still make sense to manually build the ADB? Or should it be another building block you can plug into the whole to make a bigger system?
If only DBAs can build the ADBs, they become a choke-point for anything involving that resource. The DBAs can’t delegate the work if they’re the gatekeepers. That creates friction in an organization and slows development.
My personal observation on automation is this: Tasks like creating databases are boring. Is my skill as a DBA—my understanding of the data, where it comes from, who’s using it, how it’s accessed—better spent elevating the organization (sometimes called strategic work) or doing something simple, like creating a database (sometimes called tactical work)?
The challenge and enjoyment I find in Infrastructure as Code and automation is that I can only automate something if I understand it well enough to instruct a machine to do it!
One feature of Terraform that I appreciate is it’s declarative, rather than imperative. Imperative means I have to worry about build order, how things will scale, any conditions that apply, and (usually) some implementation details. With a declarative system like Terraform, I just tell it “I want something” and Terraform does it for me!
Sunil Choudhary: can terraform be run via a browser window ?
Sean Scott: Yes, thanks for asking this! There are some third-party add-ons and front ends for Terraform that allow this. In OCI, it’s Resource Manager (not to be confused with the Oracle Database Resource Manager that prioritizes/manages database workloads). (Other cloud providers have similar tools.) You can define YAML and build an interface for OCI Resource Manager that’s accessed though the tenancy’s console. With it, users can pass variables, select options, choose items from a list based on resources available in the OCI tenancy, and even build conditional blocks that appear based on a user’s selections!
Nagaraj: Can I create these OCI resources in other compartments as well? Or will it only works under ROOT compartment?
Sean Scott: You can absolutely create resources in non-root compartments! You can even create compartments with Terraform, then assign resources to the newly created compartments!
When you create resources in Terraform, you’ll define a compartment. In the demos and scripts I tried to keep it simple by doing everything in root, but root is just a compartment, with a compartment ID that’s equal to the tenancy ID. In the scripts, you can change the destination of the resources by changing the lines that read:
compartment_id = var.tenancy_id
and substitute the desired target compartment’s compartment_id for the tenancy_id.
Thank you Sean, for the great answers!
