Actions and Events in OCI

ACTIONS

Event Rules must also specify an action to trigger when the filter finds a matching event. Actions are

responses you define for event matches. You set up select Oracle Cloud Infrastructure services that the

Events service has established as actions. The resources for these services act as destinations for matching

events. When the filter in the rule finds a match, the Events service delivers the matching event to one or

more of the destinations you identified in the rule. The destination service that receives the event then

processes the event in whatever manner you defined. This delivery provides the automation in your

environment.

You can only deliver events to certain Oracle Cloud Infrastructure services with a rule. Use the following

services to create actions:

Notifications

Streaming

Functions

EVENTS

Oracle Cloud Infrastructure Events enables you to create automation based on the state changes of resources throughout your tenancy. Use Events to allow your development teams to automatically respond when a resource changes its state. Here are some examples of how you might use Events: Send a notification to a DevOps team when a database backup completes. Convert files of one format to another when files are uploaded to an Object Storage bucket. 

You can only deliver events to certain Oracle Cloud Infrastructure services with a rule. Use the following

services to create actions:

Notifications

Streaming

Functions

Components of Resource Manager in OCI

Following are brief descriptions of key concepts and the main components of Resource Manager.

1)  CONFIGURATION 

Information to codify your infrastructure. A Terraform configuration can be either a solution or a file that you write and upload. 

2) JOB 

Instructions to perform the actions defined in your configuration. Only one job at a time can run on a given stack; further, you can have only one set of Oracle Cloud Infrastructure resources on a given stack. To provision a different set of resources, you must create a separate stack and use a different configuration. Resource Manager provides the following job types: 

i) Plan: Parses your Terraform configuration and creates an execution plan for the associated stack. The execution plan lists the sequence of specific actions planned to provision your Oracle Cloud Infrastructure resources. The execution plan is handed off to the apply job, which then executes the instructions. 

ii) Apply. Applies the execution plan to the associated stack to create (or modify) your Oracle Cloud Infrastructure resources. Depending on the number and type of resources specified, a given apply job can take some time. You can check status while the job runs. 

iii) Destroy. Releases resources associated with a stack. Released resources are not deleted. For example, terminates a Compute instance controlled by a stack. The stack's job history and state remain after running a destroy job. You can monitor the status and review the results of a destroy job by inspecting the stack's log files. 

iv) Import State. Sets the provided Terraform state file as the current state of the stack. Use this job to migrate local Terraform environments to Resource Manager.

3) STACK 

The collection of Oracle Cloud Infrastructure resources corresponding to a given Terraform configuration. Each stack resides in the compartment you specify, in a single region; however, resources on a given stack can be deployed across multiple regions. An OCID is assigned to each stack.

Steps to enable OCI Container Engine for OKE Cluster Access from kubectl CLI

Steps to enable Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE)

cluster access from the kubectl CLI?

Setting Up Local Access to Clusters

To set up a kubeconfig file to enable access to a cluster using a local installation of kubectl and the

Kubernetes Dashboard:

Step 1: Generate an API signing key pair

Step 2: Upload the public key of the API signing key pair

Step 3: Install and configure the Oracle Cloud Infrastructure CLI

Step 4: Set up the kubeconfig file

Step 5: Verify that kubectl can access the cluster