My thoughts after successful Oracle Cloud Infrastructure Developer 2020 Certified Associate exam

mattia_rossi_oci_certified_solution_architect_associate_2018Last week I was very busy so it was hard to find a few free cycles to write about it. Yes, I have passed recently Oracle Cloud Infrastructure Developer 2020 Certified Associate exam. Frankly speaking, it was obvious for me I need to do it. I am a hardcore developer here at FoggyKitchen, mostly with Terraform, but I am also writing a lot of stuff in Ansible for Oracle, for example, Ansible-Database-Migration-Tool (ADMT). You are probably curious if this certification is important and if it is worth spending time on it. Well… I guess it is. The modern world is changing like crazy. Especially now during the COVID-19 outbreak, which transforms business in an extremely fast way. I have heard that recently some big CEO has told that staying away from the cloud today would be like planing to extinct soon. Maybe this is too radical for me, but it gives a sense of mindset shift and technological revolution we are approaching today. I am not sure how it looks like at your place, but in my location, in Poland, after full lockdown, all educational activities have been moved from analog to digital. The teachers must deliver e-schooling via Zoom or on the other platforms. On the other hand, the shops are adapting very quickly to provide a nice and easy e-commerce experience with the delivery of all goodies at your footsteps in your house. For example, I was shocked it wasn’t possible to buy new shoes in the mall for my kids (full lockdown means malls are closed). The spring has approached and their feet were just bigger. There were no excuses. I have done it via e-shop…

And here is a big question. Who will build this brand new world of e-shops, e-schools, e-something, etc? There will be a massive need for cloud developers. The army of flexible programmers capable to utilize all of the features of the modern clouds. That is is why it is worth spending time on this topic – learn about OCI Event Services and OCI Functions,  explore OCI API Gateway, Oracle Kubernetes Engine (OKE),  OCI Autonomous Databases and  OCI Web Application Firewall (WAF). And of course, it is a good idea to get skills and hands-on experience with Terraform (here is my tutorial).

What do you think about it? I am very excited about your feedback in this field…

One more thing… Please remember to subscribe FoggyKitchen YT channel. 🙂

Martin, The Cook.

Building community …

I guess everybody knows it is important, but it is really difficult to start. I mean to share knowledge, then receive feedback from the followers, and ultimately stay there blogging with further efforts long term. That is the way to build a community and it is for sure hard. My idea was simple… to build the geeks community focused on Infrastructure as Code (IaC) paradigm. During the last few days, I have received a lot of positive feedback about my course and generally about this site. So it looks like my idea is valid and relevant. Now I am thinking about the future. And I am sure about one important thing. Writing alone, being a singleton, will not work efficiently. So what? So I am looking for the others, ready to join and collab here. For all IaC fans ready to join this site I have stickers! :-))) … If interested somehow, please drop me an e-mail at 🙂

Martin, The Cook.

Cook in OCI with Ansible modules – part 2

Today part 2 of the Ansible code for OCI.  Last time, within the previous blog post (part 1),  I have created OCI infrastructure with simple VM on top, right? Now let’s execute playbook no. 2. This playbook will access the VM and will install webserver software. Successful execution means the index.html page will be accessible from the outside world. Here is a code you should analyze a little bit:


As you can see we will execute the code on the machine which we have had created in step 1. But how it is derived? As you can see we will use Ansible dynamic groups, which are derived from dynamic inventory. In our case host will be derived from freeform tags, which we have had created as a part of machine launch.

It is also important to look into shell scripts which encapsulate ansible-playbook utility execution.  As you can see it will get the list of OCI hosts dynamically (please check -i parameter):

ansible-playbook playbooks/install_webserver_on_oci_compute.yml -i /home/opc/oci-ansible-modules/inventory-script/ -u opc --private-key /home/opc/id_rsa -vvv

Ok, but let’s return to playbook itself. After including variables, our code will install the httpd package, then index.html will be uploaded from the template. Finally, our local VM firewall will be disabled and httpd service will be enabled. Pretty simple.

Let’s check it up in practice. So let’s execute STEP2 of the automation…


… and after 1-2 minutes we will see the result:


Ok. This is what we have planned to have. Short story, the dish has been cooked.


Martin, MasterChef 🙂


Cook in OCI with Ansible modules – part 1

I have mentioned it some time ago. Besides of Terraform, it is possible to cook in OCI with Ansible help.  Today it is the right time to show it here. Like with Terraform you need to do some preliminary work, mostly defined in OCI docs (here is a link). Your journey with Ansible and OCI will push you in the direction of using OCI Python SDK. It shouldn’t be strange as Ansible itself is based on Python code. On top of this SDK, you will install Ansible OCI Modules available for free in GitHub repo.  I have made the assumption you already have Ansible itself, but maybe this tool you should install as well. Here is a link where you will find instructions on how to do it.

Ok, let’s assume you are ready and all software is already there, installed as required. What to do next? First, you should clone my repo from GitHub. This repo is just a simple example of how to build OCI infra (VCN and network subcomponents) and then provision simple VM within that VCN. My example will use 3 Ansible playbooks:

  • playbooks/create_oci_infra.yml – this one will create VCN and the compute/VM.
  • playbooks/install_webserver_on_oci_compute.yml – this one will install the HTTPD server within compute instance created before.
  • playbooks/teardown_oci_compute_and_infra.yml – this one will destroy compute instance and all OCI network infrastructure.

Let’s examine create_oci_infra.yml file step by step. This will be part 1. Next two blog posts will cover second and third playbooks:


As you can see above, my playbook will be executed locally. Locally in my case means ansible-server (localhost), but of course, it could be your laptop as well.

In the tasks list, the first task will include variables.yml file located in subdirectory variables. This variables.yml file will define all variables and should be modified by you as an initial step before Ansible execution (positions in yellow rectangles should be customized by you):


Ok, now let’s return to the first playbook. What do we have as a second task?

OCI_VCN Ansible module

First, we need to create a VCN within a compartment defined in variables.yml file. For that purpose, we are using oci_vcn Ansible module. We should provide some input to this module – VCN name, CIDR block, and DNS label. Task will execute the module and the results of the module will be registered in the “result” variable. In the next step, automation will set this result as Ansible’s fact (vcn_id). This will help us to create a reference to this particular VCN. It will be necessary for the rest of the OCI’s resources:



Let’s examine the next task. I guess all should be clear then.  Here we have another Ansible module called oci_internet_gateway, embodied as yet another task. This task will create InternetGateway nested in this VCN. As you can see vcn_id variable (set as a fact before) is used to define a relation between IG and VCN (highlighted in red). On the other hand, InternetGateway Id also will be stored as fact/variable for future use (to make a relationship between resources). One thing more… please notice state which is set to “present” value in opposite to other possible value – “absent”. The current code means the module will create the IG resource. Setting value to “absent” would instruct the module to tear down the resource:


OCI_ROUTE_TABLE Ansible module

Ok, let’s move forward and continue to decompose the playbook. The next task is related to the route table. Here we will use oci_route_table Ansible module. Again we are making a reference to VCN (vcn_id) as well as to Internet Gateway (ig_id). On the other hand, we are storing route table id in “rt_id” fact/variable just after task will be executed:


OCI_SECURITY_LIST Ansible module

The next step will be more complex. We will use Jinja2 (j2) templates stored in templates subdirectory. They will help us to create ingress and egress rules for OCI Security List. In practice, it means templates files will be loaded and all variables will be derived and changed into proper values. Then files will be stored as yaml files, printed out and loaded as dynamic variables (loaded_ingress & loaded_egress). As the last step, they will be used to execute yet another Ansible module called oci_security_list. For the purpose of this module, we will also do the reference to VCN (vnc_id). As a result, we will have an additional variable instance_security_list_ocid (as an Ansible fact):


OCI_SUBNET Ansible module

It looks like we have all of the infra components needed for the subnet to be constructed. For subnet provisioning, we will use the oci_subnet Ansible module as follows. In the code body, we will use vnc_id as well as instance_security_list_ocid and rt_id variables. These dynamic variables have been created before. The rest of the module options will be populated as always from the variables.yml file included at the very beginning of this playbook. As a result of the execution we could expect registered output and this output will be stored in yet another variable called instance_subnet_id:


OCI_INSTANCE Ansible module

It looks like our foundation is ready and we can cook the VM itself. For that purpose, we have the next task which will use oci_instance Ansible module. Again we will use a dynamic variable. This time it will be instance_subnet_id (set as a fact in the previous step). Keep in mind this instance will be tagged with freeform tag (tier=webserver). It will be used for the purpose of Ansible dynamic inventory (it will be covered by part 2 of this blog).



The process of VM spin-up uses to take 2 or 3 minutes in OCI. Next 1-2 minutes we need to wait for the SSH server to be started. As so our playbook code needs to obtain the public IP of this brand new machine and then wait until the machine will be really ready. We will require the next two Ansible modules – oci_vnic_attachment_facts module for VNIC attachment and then, in cascade, oci_vnic_facts module for VNIC itself and public IP address – VNIC’s attribute.

We can evaluate playbook execution as successful only if it will be possible to access the machine with SSH protocol and then execute some simple command remotely. Let’s say it will be “uptime” Linux command, ok? All of that you can see below, in the last part of the playbook:


Ok. It looks like we know exactly what is this playbook for. Let’s now execute it. To do it we can use the shell script in the root directory. This shell script encapsulates ansible-playbook utility with all necessary parameters:


Ok. Now it is a time for execution. Let’s start with Ansible. After 5-6 minutes we should have this outcome in the Linux terminal:


On the other hand in OCI UI we should see this result as follows:


And that is the end of part 1. Next time I will explain how to start second and third playbook from the repo.

Bon Appetit,

Martin, The Cook 🙂