Microservice architecture has its perks, and orchestration systems sure do help to alleviate its pitfalls. Sooner or later, though, developers end up with a bunch of scripts to manage all the steps required to deploy your architecture.
With capitana
, you'll be able to control all the things your orchestration system can't quite reach.
Forget about
./build-database-prod.sh./build-api-prod.sh./build-database-prod.sh
and start capitana build --environment prod --all
!
Installation
npm
Using$ npm install --global capitana
npx
Using$ npx capitana [stage] [microservices] [options]
Usage
$ capitana --help Usage capitana [stage] [microservices] [options] Options --all Execute program on all microservices. --break Stop execution on execution failure. --config filePath Specifies a different config file to use --except microservices Exclude microservices from execution. --full Executes all stages on the selected microservices. --help Show this message and exit. --interactive Executes capitana interactively. --list [ "variables" | "microservices" | "stages"] List configured variables. --listAllowed [ microservice | stage ] Lists the stages a microservice is allowed to run through or the microservices allowed to run through a stage. --no-spinner Disables spinner. Useful
Configuration file
Capitana is heavily dependant on its own .capitanarc
configuration file. For the time being, the only way to mahe capinana
respect this configuration file is to create it on the folder you're gonna be running capitana
on.
Example configuration file:
microservices: database: ~ load-balancer: allowedStages: - tag - deploy server: ~stages: build: run: npm run build cwd: $MICROSERVICE deploy: run: kubernetes apply -f deployment-$environment-$tag.yaml variables: - environment - tag cwd: $MICROSERVICE push: run: docker-compose push cwd: $MICROSERVICEvariables: environment: - dev - test - prod tag: - latest - "1.0" defaults: tag: "latest"
License
MIT © LTS Beratung