ops
, the Apache OpenServerless all-mighty CLI tool.Quick install in Linux, MacOS and Windows with WSL or GitBash:
curl -sL bit.ly/get-ops | bash
To be implemented: quick install in Windows with PowerShell
irm bit.ly/get-ops-exe | iex
ops
?Well, as you can guess it helps with operations: ops
is the OpenServerless CLI.
It is a task executor on steroids.
task
wsk
ops -help
)The predefined set of tasks are all you need to install and manage an OpenServerless cluster.
You can also use it for your own purposes, if you want.
Because ops
is built on task
, docopt
and wsk
you have to consult the following websites for:
opsfile.yml
: taskfiles
docopts.txt
: docopts
ops
looks for tasksOps is able either to run local tasks or download them from GitHub.
Tasks may also contain prerequisite binaries, and task
will download them automatically and put then in the PATH
.
See below for details
When you run ops [<args>...]
it will first look for its ops
root.
The olaris
root is a folder with two files inside: opsfile.yml
(a yaml taskfile) and opsroot.json
(a json file
with release information).
The first step is to locate the root folder. The algorithm to find the tools is the following.
OPS_ROOT
is defined, it will look there first, and will check if there are the twoopsfile.yml
. If there is, it will also lookopsroot.json
. If it is not there, it will go up one level looking for a directory with opsfile.yml
opstools.json
, and selects it as the ops
root.opsfile.yml
it will look for a folder called olaris
with both a opsfile.yml
opstools.json
in it and will select it as the ops
root.~/.ops
if there is an olaris
folder with opsfile.yml
and opsroot.json
.If the local task resolution fails, it will download its tasks from Github.
It is the same process that you can trigger manually with the command ops -update
.
ops
download tasks from GitHubThe repo to use is defined by the environment variable OPS_REPO
, and defaults
to https://github.com/apache/openserverless-task
The branch to use is defined at build time. It is noramlly named as the base version of the CLI. It can be overriden
with the enviroment variable OPS_BRANCH
.
When you run ops -update
, if there is not a ~/.ops/<branch>/olaris
it will clone the current branch, otherwise it
will update it.
ops
execute tasksOps
will look to the command line parameters ops <arg1> <arg2> <arg3>
and will consider them as directory names. The
list can be empty.
If there is a directory name <arg1>
it will change to that directory. If there is then a subdirectory <arg2>
it
will change to that and so on until it finds a argument that is not a directory name.
If the last argument is a directory name, will look for a docopts.txt
. If it is there, it will show this. If it's not
there, it will execute a ops -task -t opsfile.yml -l
showing tasks with description.
If it finds an argument not corresponding to a directory, it will consider it a task to execute,
If there is not a docopts.txt
, it will execute as a task, passing the other arguments (equivalent
to ops -task -t opsfile.yml <arg> -- <the-other-args>
).
If there is a docopts.txt
, it will interpret it as a docopt
to parse the remaining arguments
as parameters. The result of parsing is a sequence of <key>=<value>
that will be fed to task
. So it is equivalent to
invoking task -t opsfile.yml <arg> <key>=<value> <key>=<value>...
A command like ops setup kubernetes install --context=k3s
will look in the folder setup/kubernetes
in the ops root,
if it is there, then select install
as task to execute and parse the --context=k3s
. It is equivalent to
invoke cd setup/kubernetes ; task install -- context=k3s
.
If there is a docopts.txt
with a command <name> --flag --fl=<val>
the passed parameters will
be: _name_=<name> __flag=true __fl=true _val_=<val>
.
Note that also this will also use the downloaded tools and the embedded commands of ops
.
Currently task embeds the following tools, and you can invoke them directly prefixing them
with -
: (ops -task
, ops -basename
etc). Use ops -help
to list them.
This is the list of the tools (it could be outdated, check with ops -help
):
Available tools:
-awk
-base64
-config
-datefmt
-die
-echoif
-echoifempty
-echoifexists
-empty
-envsubst
-extract
-filetype
-gron
-help
-info
-jj
-jq
-login
-needupdate
-plugin
-random
-remove
-rename
-replace
-retry
-serve
-sh
-task
-update
-urlenc
-validate
-version
-wsk
As a convenience, the system sets the following variables and you cannot override them:
OPS
is the actual command you are using, so you can refer to ops itself in opsfiles as $OPS
.OPS_PWD
is the folder where ops
is executed (the current working directory). It is used to preserve the originalops
changes to the acutal folder where the tasks are for execution.The following environment variables are always set and you can override them.
OPS_CMD
is the actual command executed - defaults to the absolute path of the target of the symbolic link but it canOPS
will take this value.OPS_VERSION
can be defined to set ops's version value. It is useful to override version validations when updatingOPS_HOME
is the home dir, defaults to ~/.ops
OPS_REPO
is the github repo where ops
downloads its tasks. If not defined, it defaultshttps://github.com/apache/openserverless-task
.OPS_BRANCH
is the branch where ops
looks for its tasks. The branch to use is defined at build time and it isbranch.txt
for the current valueOPS_ROOT
is the folder where ops
looks for its tasks. If not defined, if will follow the algorithm described$OPS_REPO
in$OPS_BRANCH
and store it is $OPS_HOME/$OPS_BRANCH/olaris
.OPS_BIN
is the folder where ops
looks for binaries (external command line tools). If not defined, it defaults~/.ops/{{.OS}}-{{.ARCH}}/bin
. All the prerequisites are downloaded in this directory. It is automatically addedOPS_TMP
is a temporary folder where you can store temp files - defaults to ~/.ops/tmp
OPS_APIHOST
is the host for ops -login
. It is used in place of the first argument of ops -login
. If empty, theOPS_USER
is set the username for ops -login
. The default is nuvolaris
. It can be overriden by passing theops -login
or by setting the environment variable.OPS_PASSWORD
: set the password for ops -login
. If not set, ops -login
will prompt for the password. It is usefulOPS_ROOT_PLUGIN
is the folder where ops
looks for plugins. If not defined, it defaults to the same directoryops
is located.OPS_PORT
is the port where ops
will run embedded web server for the configurator. If not defined, it defaults9678
.OPS_OLARIS
holds the head commit hash of the used olaris repo. If it is a local version its value is <local>
. Youops -info
.The following variables have a special purpose and used for test and debug:
DEBUG
if set enable debugging messages.TRACE
when set gives mode detailes tracing informations, also enable DEBUG=1
.EXTRA
appends extra arguments to the task invocation - useful when you need to set extra variables with a docopts__OS
overrides the value of the detected operating system - useful to test prereq scripts.__ARCH
overrides the value of the detected architecture - useful to test prereq scripts.OPS_RUNTIMES_JSON
is used for the values of the runtimes json if the system is unable to read in other ways theOPS_COREUTILS
is a string, a space separated list, which lists all the commands the coreutils binary provided. ItOPS_TOOLS
is a string, a space separated list, which lists all the commands provided as internal tool by the opsOPS_NO_DOCOPTS
can be defined to disable docopts parsing. Useful to test hidden tasks. When this is enabled it alsoOPS_NO_PREREQ
disable downloading of prerequisites - you have to ensure at least coreutils is in the path to make