Automating Start and Stop of OCI Resources with OCI Resource Scheduler
A step-by-step Console walkthrough for putting compute and database resources on a fixed start/stop timetable.
If you run development, test, or demo workloads on Oracle
Cloud Infrastructure (OCI), some of those resources almost certainly sit idle
for large parts of the day and night. OCI Resource Scheduler lets you put them
on a fixed timetable — automatically stopping compute instances and databases
when nobody needs them, and starting them again before the work day begins.
This post walks through creating a schedule end to end in
the OCI Console, based on a real auto-start/stop setup with separate
application and database nodes.
NOTE: I didn’t provide exact screenshots from the console to
protect confidential data.
What Resource Scheduler does
Resource Scheduler is an OCI service for automatically
starting and stopping resources on a recurring schedule. It supports compute
instances and autonomous databases, and the Console notes that other resource
types may be supported in future releases. The typical use case is
non-production environments: instead of being billed for compute and database
resources around the clock, you keep them running only during the hours they
are actually used.
Before you start: the IAM policy
Resource Scheduler is integrated with OCI Identity and
Access Management (IAM). A valid IAM policy that enables scheduling management
must be in place for each resource type you want to schedule. The wizard states
this explicitly on its Review step and provides a Review policies
link so you can confirm it before you commit the schedule.
Step 1 — Open the Schedules page
From the OCI Console, open the navigation menu and go to Governance
& Administration → Resource Scheduler → Schedules.
Step 2 — Select the compartment
On the Schedules page, set the Compartment
filter to the compartment that holds the resources you want to schedule. Any
schedules that already exist in that compartment are listed here, along with
their status, action, last run, and next run date.
Step 3 — Create a schedule: General information
Select Create a schedule. On the first page of the
wizard you provide the following inputs:
- Schedule
name and Schedule description.
- Action
to be executed — Start or Stop.
- Resource
selection method:
- Static
— apply the schedule to a specific list of resources that you choose now.
- Dynamic
— apply the schedule to all resources that match a search criteria at the
time the schedule runs.
- Compartment
for the schedule.
- Tags
(optional) — useful for organising and tracking your schedules.
In this walkthrough, Static selection is used, so the
schedule always acts on an explicit, known set of resources.
Step 4 — Select the resources
On the Resources page, choose the resource or
resources the schedule should act on. You can filter by compartment and
resource type, then tick the specific resources — for example, a single
application compute instance.
Step 5 — Apply parameters
The Apply parameters page lets you optionally pass a
JSON body to the action for the selected resources. For a straightforward
start/stop schedule there is nothing to change here — leave it as-is and
continue.
Step 6 — Define the schedule
On the Schedule page you set when the action runs.
You can specify the timing two ways:
- Form
interface — choose an interval (for example, Daily), how often
it repeats, a time, and start/end dates.
- Cron
expression — enter a cron expression directly.
Schedule times are entered in UTC. Account for your
local time-zone offset when choosing the time. The Summary line confirms
the resolved schedule — for example, Every day at 03:45 UTC.
Step 7 — Review and save
The final Review page summarises the schedule: name,
action, resource selection method, the resources chosen, and the recurrence
details including the first run date. Two things are worth checking here:
- Notifications
— you can optionally connect the schedule to the OCI Notifications service
to be alerted when it runs.
- Policies
— use the Review policies link to confirm that the IAM policy for
the selected resource type is in place.
When everything looks correct, select Save schedule.
The result
The new schedule appears on the Schedules list with
its status (Enabled or Disabled), resource criteria, recurrence,
action, last run result, and next run date.
A practical tip: order matters for multi-tier workloads
For a typical multi-tier application, the database and
application tiers should not start at the same time. The database node needs
to be started before the application node, because a multi-tier application
generally needs its database tier available before the application tier comes
up.
The way to handle this with Resource Scheduler is to create separate
schedules per tier and offset their times. In the environment shown above,
the auto-start schedules are split into a DBCS (database) schedule and an
Application node schedule, with the database schedule set to run first. If
shutdown order also matters for your workload, you can apply the same idea in
reverse for the Stop schedules.
Wrapping up
Resource Scheduler turns "remember to shut the dev
environment down" into a one-time configuration. Create a Start schedule
and a Stop schedule per tier, mind the UTC offset, sequence the tiers
correctly, and confirm the IAM policy — then let the service run on its own.
References
- Oracle
Cloud Infrastructure — Resource Scheduler documentation: https://docs.oracle.com/en-us/iaas/Content/resource-scheduler/home.htm
Debapriya Biswas
Oracle ACE Apprentice | Sr. Consultant – Cloud Technologies
Focused on OCI Compute, Networking, and Automation
Comments
Post a Comment