Howdy|out|there in automation land! It has been 1 year.... 1 year exactly since my last blog. I do apologizetothe readers but with the year we've had, I am sure you understand. A lot of change in our work environments, a lot of change in our world. However, Pondering Automation is backandin a new place/home. This blog will movetothe developer blogs section of cisco.com now and will be here for the duration!

Summer is here and I hope everyone has the chancetostep back, take some time, have a vacation, do whatever makes you feel good. You know what makes me feel great? Automation, Orchestration, and making our lives' easier! Pondering Automation has been backed with Python, Cisco Process Orchestrator, and Action Orchestrator throughout its multi-year past... but now we are moving ontoSecureX Orchestration! And since we are bringing in some new readers and starting some new(er) beginnings, maybe our movie poster should be....

A movie I have not seen yet but appropriate for today's "restart" of the blog... no? So great, we are back... what do I have for you today? Well today we are goingtocover a handful of things and solve a use-case while using SecureX Orchestration or SXO. SXO resides in our SecureX platform and is locatedin thepublic cloud. You are saying... "that is great! Software as a service!"... but then you are also thinking... "how do I get to my on-premise components?" Well, the answer for you is the SXO Remote!

Now this is not a blog focused on the Remote... but you will need the remote for the blog. You can find some outstanding documentation on the remote, its setup, and more on the SecureX Documentation Git. What we are going to do today, instead, is we are going to solve this problem: I need to use a database with my SXO automations and I want that database to be on-prem... how do I do that with the pieces we have today? Well... let me show you! Does this only have to relate to a Security automation or use-case? No. This is purely a generic use-case in nature and could be applied to any and all automations you want to do with SXO... the possibilities are limitless for such a great product. Apologies if this looks like a recipe... I do love to cook. And after I show you all the goodness... I also have a bunch of atomics pre-build for this setup that I am going to share with you

What you will need...

1. SecureX Orchestration
2. SecureX Orchestration Remote that is already connected (see above Git for steps/videos)
3. An on-prem Linux Virtual Machine -I prefer using CentOS and will write based on that
4. About 30 minutes to deploy and connect

How To Steps....

MongoDB

I are assuming you have SXO and your SXO Remote is connected. I am also assuming you have a VM ready to be your DB. First, we will select MongoDB as our DB of choice and we will need to install it to our VM.

1. Personally I like to disable the firewall first, but up to you... if so you can disable viasystemctl disable firewalldor you can punch holes in it if you like.
2. Next we want to update our yum repos viayum -y update
3. Now we need to include Mongos repo. We are going to create the repo file viavi /etc/yum.repos.d/mongodb-org.repoand we will use Mongo 4.4 , so you can use this as your repo configuration:

   [mongodb-org-4.4]
   name=MongoDB Repository
   baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/
   gpgcheck=1
   enabled=1
   gpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc

4. You can verify this withyum repolistand then install mongo viayum install -y mongodb-org
5. We will be using the default directories so a default install is just fine. If you wish to use different directories then follow the Mongo documentation linked above to do such.
6. Turn off SELinux if you can viasetenforce 0and then permanently viased -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
7. Edit your mongo configuration file viavi /etc/mongod.conf, change thebindIpfrom127.0.0.1 to 0.0.0.0to allow for other hosts to connect
8. Enable mongo viasystemctl enable mongodand then start it viasystemctl start mongod. Verify the service viasystemctl status mongod
9. You can create a user by going into mongo viamongoat the command line.
10. You can then use this line to create an administrator user with user nameadminand passwordCisco

use admin
db.createUser( { user: "admin", pwd: "Cisco", roles:[{role: "userAdminAnyDatabase" , db:"admin"}]})

RestHeart -API Layer

Now mongoDB is installed. We need to add a Rest API layer on top of it so we can use the remote and SXO to talk to the DB. To add our Rest API layer, we will use RestHeart. This is an opensource/free project that will add the API layer. It is not the only one out there but I found it to be super easy to configure, use, and is highly responsive. This setup of Rest API over DB can be done across many DBs (mongo, mySQL, Oracle, etc) and with many Rest API servers. So let's follow the setup to install it...

1. Make an install directory viamkdir -p restheart
2. You will need to install java if you do not already have it. The most current version of restheart uses Java 16, so you would need to runyum install java-16-openjdk-devel-y. You can verify it viajava -version. If you don't see 16, maybe you see 8 or 11 or an older version here. To set your version, you will need to then runalternatives --config javaand select the number that matches version 16.
3. Download restheart viawget https://gitreleases.dev/gh/SoftInstigate/restheart/latest/restheart.tar.gz. And expand the tar viatar -xzf restheart.tar.gz
4. You should edit thedefault.properties in the etcfolder inside of restheart.
5. You can change whatever you like inside of this configuration file, but the big one to point out is to change theroot-mongo-resource to '*'and this will give it access to all of your DBs in mongo.
6. To start restheart in the background run the following command:java -jar restheart.jar --fork etc/restheart.yml -e etc/default.properties
7. The default users are in theetc/users.ymlfile and we will use the base default which is user:adminand password:secret
8. You can make a couple curls to test restheart.
9. First, we will create a DB viacurl --user admin:secret -I -X PUT localhost:8080/BlogTest
10. Next we will create a collection viacurl --user admin:secret -I -X PUT localhost:8080/BlogTest/Demo
11. Lastly we will insert some data to the collection viacurl --user admin:secret -H "Content-Type: application/json" -X POST localhost:8080/BlogTest/Demo -d '{"some": "test", "for": "blog"}'

Integration with SXO

1. Now we have our DB setup and listening to our API requests! We can use a simple HTTP Request call in SXO to do DB work.
2. First let's create a target. Go to the targets menu and select to create a new target.
3. You will need to create a new account keys and it should be the *RestHeart* API user, not the MongoDB user. It is basic authenication.
4. Select your Remote for SXO.
5. Input yourhost IP or addressof the on prem VM. Use Port8080if you are using the default for RestHeart. UseHTTPunless you changed that on RestHeart. No path is needed.
6. Now we will create a new test workflow, so go back to the workflows area and clickNew Workflow
7. Search for theHTTP Requestactivity and drag and drop it to your canvas. Select your mongoDB rest API target as the target.
8. Set therelative URL to BlogTest/Demoor basically<DB>/<Collection>
9. Set theMethod to GET and Content Type to JSON
10. Validate and run your workflow. You should see the sample data we inserted earlier on! You have now queried an on-prem DB from the SXO cloud!

To help you guys, I have a few things to give you... one is 13 atomic workflows to use on this setup! So if you like this and want to use Mongo(I know I will) in SXO, then you can use the MongoDB-RestHeart atomics found on the public CX Workflow git. Please note: These workflows are "opensource" in nature and have no support. However if you find a bug... let me know!

Lastly... as with all of my blogs, there is a video of me doing it... sooooo

Onto the Video!

Link: The House that Automation Built-20210607 1920-1

Pass: DbmBBCe3

Standard End-O-Blog Disclaimer:

Thanks as always to all my wonderful readers and those who continue to stick with and use CPO and AO! I have always wanted to find good questions, scenarios, stories, etc... if you have a question, please ask, if you want to see more, please ask... if you have topic ideas that you want me to blog on, Please ask! I am happy to cater to the readers and make this the best blog you will find

AUTOMATION BLOG DISCLAIMER: As always, this is a blog and my (Shaun Roberts) thoughts on CPO, AO, SXO, orchestration, development, devops, and automation, my thoughts on best practices, and my experiences with the products and customers. The above views are in no way representative of Cisco or any of it's partners, etc. None of these views, etc are supported and this is not a place to find standard product support. If you need standard product support please do so via the current call in numbers on Cisco.com or email [email protected]

Thanks and Happy Automating!!!

- Shaun Roberts,  [email protected]

Related resources

• Getting started with Cisco Security APIs
• Learn about Cisco network programmability

We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel