• Beta
How to Configure ops.yml & Dockerfile
  • 17 Feb 2021
  • 6 Minutes To Read
  • Share
  • Dark
    Light

How to Configure ops.yml & Dockerfile

  • Share
  • Dark
    Light

Configuring Workflows

There are two main files that you can configure in workflows: the ops.yml and the Dockerfile. If you deploy your app to CTO.ai, you will be provided a pre-configured ops.yml and Dockerfile. However, you can also manually configure them for Commands, Pipelines and Services.

ops.yml

The ops.yml file structures how your work will run and provides information for how other users will be able to interact with it.

The run line of the YAML is the entry point command that is run as the final step of the Dockerfile to trigger your workflow. In general, this is the only difference in the YAML file between workflows made for different languages.

The example template shown below is an ops.yml created by ops init for a Service. There are a number of different flags you can specify in this file, as described in the ops.yml settings section below. A similar ops.yml file will be generated for Commands and Pipelines. For details on Pipeline-specific configuration, please review our Pipeline doc.

version: "1"
services:
  - name: Apptest2:0.1.0
    description: my app description
    run: "node /ops/index.js"
    port: [ '8080:8080' ] ## Port only required for Services
    domain: ""
    env:
     static:
        - DB_PORT=5050
      configs:
        - config_name
      secrets:
        - secret_name 
    events: "github:cto-ai-github/node-service-test:push:ref==master"
    trigger:
     - build
     - publish
     - start
Note

If any of the ops.yml flags are left blank, the flag will use the default value. To see a complete set of flags in the ops.yml, you can see the example below.

Environment variables

As shown above, the ops.yml file also includes an env property that allows you to provide required environment variables for workflows from our Config and Secrets features. You can set both secrets and configs from either the CLI or our WebUI.

Note

You must specify your secret or config in your ops.yml to be able to use it.

In the environment variable property, you can specify secrets and configs.
These environment variables are automatically pulled from the respective storage by name.
For example, if you were to store the password for your database in a Secrets value called DB-PASS. Then, when you use that variable under secrets in env it will automatically pull in your database password to be used where needed (see yml above for this usage).

Note

If you specify a secret or config that does not already exist in your secret/config store, it will produce a blank value.

Once you have set secrets & configs on CTO.ai and in your ops.yml, you can treat them as any other variable in your code. You can follow a more detailed guide in the Secrets & Configs as Environment Variables docs.

Warning

Environmental variable names cannot start with a number.

Static Variables

It is also possible to set static variables in the ops.yml. These environment variables do not need to be hosted in your secret or config store. In the example above you will see we've set both variables KEY and DB_PORT to specific values.

Fetching Environment Variables in code

You can also fetch environment variables in code. You can use the sdk.getSecret() function. You can find a node example of secrets and configs in the Node SDK documentation.

Notes

Different types of workflows have their own unique ops.yml characteristics. You can find out more in the specific documentation for Pipelines and Services.

Dockerfile

The Dockerfile provides the build instructions to include all of the files and software packages necessary to run the workflow. This sample Dockerfile was created with ops init for a JavaScript Service.

############################
# Final container
############################
FROM registry.cto.ai/official_images/node:2-12.13.1-stretch-slim

WORKDIR /ops

ADD package.json .
RUN npm install

ADD . .


Container File Permission Consideration

Following security best practices and to ensure no malicious processes are executed within the Pipeline, Service, or Command, the Workflow containers are run in non-privileged mode (with non-root user). To be more specific, the containers run with user and group set to 9999.

This means that running specific commands or attempting to execute actions that require root privileges post-build (as part of the container running) will not work as expected unless the right configuration is done as part of the Dockerfile. For writing files, we recommend using the /home/ops or /tmp directories, as those are set up by default as writeable. Additionally, if your workflow requires write access to a specific directory beyond the default ones, set the ownership of that location to user 9999 by adding additional arguments --chown=9999 to the ADD or COPY commands in the Dockerfile. Alternatively, you can RUN a chmod o+w command on the files/directories that you want writeable.

Docker Technical Info

  • registry.cto.ai/official_images/base:2-stretch-slim, adds the needed SDK binaries in /bin to the base Debian image.
  • registry.cto.ai/official_images/node:2-12.13.1-stretch-slim, has Node.js included on top of what is provided by the base image. Currently, this includes version 12 of Node.js.
  • registry.cto.ai/official_images/python:2-3.7-buster-slim, has Python 3 included on top of what is provided by the base image.
  • registry.cto.ai/official_images/bash:2-buster-slim, has Bash included on top of what is provided by the base image.

Settings

Ops.yml Settings

CTO.ai has many standard and optional .yml settings that you can use to better leverage our platform. If a value is unspecified, it will be set to its default value.

Below is a list of different settings you can use in your ops.yml.

name (required)

The unique identifier for your workflow, followed by the version number.
name: workflowname:x.xx

run (required)

The command that executes when a workflow is started.
run: node /ops/index.js

domain

Allows you to configure a domain for your Service. See Domains and CNAME on how to use this setting. This is only used in a Service ops.yml.
domain : "mydomain.com"

port

This is the port defined for your Service. This is only used in a Service ops.yml.
port : 8080

env

This sets environment variables that can be used in your App. You can set secrets, configs, or static env variables. See Environment Variables section above for more information.

env:
      configs:
        - config1
      secrets:
        - secret1
      static:
        - staticEnv1 = 8080
      

events

The events flag lets CTO.ai know the source of events and what specific event to list to trigger an operation.

ex. โ€œgithub:org_name/repo_name:push:ref==mainโ€

triggers

Event triggers let CTO.ai know what operation to take when an event occurs. This can be build, publish, or start.

Note

Read the How to Use Events and Triggers for more information on how to leverage these in your workflow.

description

This is a text field that provides a brief description of the workflow visible to other users.

version

The platform version for the ops.yml syntax
The version of the Workflow is captured in the name: field.

Legacy Settings

public

It is a legacy setting that specifies whether a version of a workflow is visible in our Public Registry.

Vaules: false or true.
Default: public: false

remote

It is a legacy setting that specifies if a workflow will be allowed to run remotely(true) or if the workflow can only be run locally(false).
default value: true
remote: true

sdk

It is a legacy setting that specifies the CTO.ai SDK version to use.
default value: 2.

sourceCodeURL

It is a legacy setting for the Registry. It allows adding a link to a public Github repo or a markdown file. The README.md will be displayed on your workflow page in our Registry.

mountCwd(run local only)

A setting for testing a locally run Workflow only. If set to true, this will bind the host's current working directory to /cwd.
Default= false and will use working directory /ops.

mountHome(run local only)

A setting for testing a locally run Workflow only. If set to true this will bind the host's home directory to /root. The default value is false.

๐Ÿš€ What's next?


๐Ÿ“ž Need help? No problem!


Was This Article Helpful?