Workflow Locally - woveon/wovtools GitHub Wiki
< Home : Workflow > Workflow Locally - Workflow On Cluster - Workflow To Cluster - Workflow Rolling Stages

-
Project Creation - Run wov-init to transform your existing project into a WovTools project. This will make changes to your git setup, and create a wovtools directory.
-
Create K8s Context - Make sure you have a context in Kubernetes for your namespace ({PROJECT}_{STAGE}).
-
Set Stage - By default, wov-init will exist in your user's stage, but
wov-stage <stage>sets the stage for development. So,wov-stage devorwov-stage prodare two different stages. However, I use my initials for stages, creating my own Kubernetes namespace and git branch to work in. So,wov-stage cwis what I start in. -
Secrets - You need to start moving configuration information into json files in wovtools/secrets. These files are merged together according to the order in wovtools/secrets/config.json. Also, secrets need to be managed in a safe way. They are stored in a git repository, so we can version the secrets, but you need to ensure the repo is hosted in a secure/encryped location. NOTE: GitHub is not encrypted by default. While your commands will differ, you will use commands similiar to this to commit your secrets to Git:
git remote add origin *URL* # set origin to remote URL
# ex. for AWS CodeCommit: git remote add origin https://git-codecommit.us-east-1.amazonaws.com/v1/repos/reponame
git remote -v # test connection
git push -u origin master # send data to remote master
-
Env: variables - Using environment variables is the safe way to run containers and Kubernetes, as you add them at runtime and do not store them in the repo. Create
.wovfiles in 'wovtools/conf' which are compiled for use in bash shells, Makefiles, Kubernetes ConfigMaps and Secrets, etc. Use.ck8s.wovfor non-secret data and.sk8s.wovfor data that needs to remain encryped (passwords, keys, etc). See wov File Format below. -
Env: Kubernetes Yaml - Move your Kubernetes yaml files into the
wovtools/k8sdirectory and append thewovextension. Then modify the files to use the secrets you compile from the Env files. NOTE: follows the wov File Format as shown below. -
Env: Build - Run the
wov-build -scommand to compile the secrets and thenwov-build -eto compile the Env'swovfiles with this secret. These files are only built as needed (dependencies on timestamps secret diffs) sowov-build -vcan print which files are skipped. Also,wov-build -eincludes the-sstep so justwov-build -ewill build the Env in one step. -
Services - Write scripts that emulate the services your code will interact with in the cluster. This includes databases or other microservices. Write scripts in wovtools/services as SERVICE.sh, SERVICE-test.sh, SERVICE-kill.sh, which correspond to
wov-serviceswitches of -r, -t and -k. -
Cmds - Create commands in the
cmdsdirectory that are run withwov-cmd. This are things kile url checks or database access. -
Develop - Build your code. Whatever you do, create that code. To use environment variables, use the
wov-envscript to set them, and then set them before your command is run.
# To run service myprojectservice1 with environment vars created with wov-build on file 'wovtools/conf/env.ck8s.wov':
env `wov-env --cmd env.ck8s` npm run myprojectservice1
# To bring the variables locally (not env, so won't be passed to scripts
eval $(wov-env --env env.ck8s)
export WOV_plugin_desc # now it is global so can be used in a called script
# To use in Makefiles, dump to a file and include
$(shell wov-env --env env.ck8s > ./.wovtools.mk)
include ./.wovtools.mk
# To get a single WovTools variable (ex. 2):
wov-env --var WOV_PVER # returns 'WOV_PVER=2'
# To get all WovTools variables:
wov-env -e
-
Git -
wov-pushcode-check- Make sure your git archive, and also your wovtools/secret git archive, are checked in and pushed. -
Containers - Build the containers with the
wov-push-containers. This involves creating scripts to create the content that goes into the container. For each container, created a script.sh file inwovtools/containersfor that container. Variables passed to the script are CONTAINER (name of the container), SRCDIR (the root of the project) and DESTDIR (the directory the files are dumped). Make sure to include a Dockerfile as well. When your recipes are created, run thewov-push-containerscommand. To list containers this will build, runwov-push-containers -l. -
k8s files - Push the env files to archive with
wov-push-env.
NOTE: wov-push will do this entire process...
-
Deploy - Run
wov-deployto run the latest project. This pulls env files and runs them. These files in turn include the Kubernetes deployments, which pull the containers. To run older versions, do awov-deploy --pver X --sver Yto run different versions. Note that only valid combinations of project and secret versions are allowable.