How to Configure ops.yml & Dockerfile
- Updated On 17 Feb 2021
- 6 Minutes To Read
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 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
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.
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.
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
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
env it will automatically pull in your database password to be used where needed (see
yml above for this usage).
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.
Environmental variable names cannot start with a number.
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
DB_PORT to specific values.
Fetching Environment Variables in code
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
############################ # 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
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
/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
COPY commands in the
Dockerfile. Alternatively, you can
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
/binto 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
baseimage. 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
registry.cto.ai/official_images/bash:2-buster-slim, has Bash included on top of what is provided by the
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.
The unique identifier for your workflow, followed by the version number.
The command that executes when a workflow is started.
run: node /ops/index.js
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"
This is the port defined for your Service. This is only used in a Service
port : 8080
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
The events flag lets CTO.ai know the source of events and what specific event to list to trigger an operation.
Event triggers let CTO.ai know what operation to take when an
event occurs. This can be
Read the How to Use Events and Triggers for more information on how to leverage these in your workflow.
This is a text field that provides a brief description of the workflow visible to other users.
The platform version for the
The version of the Workflow is captured in the
It is a legacy setting that specifies whether a version of a workflow is visible in our Public Registry.
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).
It is a legacy setting that specifies the CTO.ai SDK version to use.
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
false and will use working directory
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
🚀 What's next?
- Start setting up your own Services on CTO.ai
- Connect your Database to your application
- Get started by setting Secrets & Configs as environment variables
- Learn More about our SDK