Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

kit-deployer

Package Overview
Dependencies
Maintainers
1
Versions
137
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

kit-deployer

Use to deploy files to multiple kubernetes clusters.

  • 6.4.0
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
29
increased by11.54%
Maintainers
1
Weekly downloads
 
Created
Source

kit-deployer

Codeship Status for InVisionApp/kit-deployer Docker Repository on Quay npm version Dependency Status devDependency Status

Use this service to deploy files to multiple Kubernetes clusters. You just have to organize your manifest files into directories that match the names of your clusters (the name defined in your kubeconfig files). Then you just provide a directory of kubeconfig files and the kit-deployer will asynchronously send all manifests up to their corresponding clusters.

There is also support for namespaces. Simply provide a directory with namespaces that are grouped into folders that match the name of the kubeconfig cluster you want them deployed to.

The kit-deployer service was designed to work for a CI type service like Codeship where it can be run as a docker image as part of your automated workflow. However, you can also use it as an npm module or as a CLI tool directly.

Use as Docker Image

docker run quay.io/invision/kit-deployer --help

We recommend using kit components with Codeship's Docker Infrastructure, however you are free to run this tool however way you wish. Anything that has Docker can run this image.

Using as CLI

You can run the ./src/deployer --help to see how it works.

Note this method requires node and was tested on version 5.5.0.

Using as npm module

Use npm to install kit-deployer:

$ npm install kit-deployer --save

Then require it and use it like so:

var Deployer = require("kit-deployer").Deployer;

var options = {
	sha: "c6350f4c2709708b8f784408a440030e704b2b9a",
	dryRun: true,
	diff: true,
	github: {
		token: "ccd50691c75bc7bae0a5490ea08ff9dcc9c264a5",
		user: "chesleybrown",
		repo: "my-app"
	}
};

var deployer = new Deployer(options);

// setup logging of events
deployer.on("info", function(message) {
	console.log(message);
});
deployer.on("warn", function(message) {
	console.log(message);
});
deployer.on("error", function(message) {
	console.log(message);
});
deployer.on("fatal", function(message) {
	console.log(message);
});
deployer.on("status", function(status) {
	console.log(status);
});

deployer
	.deploy("/configs/**/kubeconfig", "/manifests", "/namespaces")
	.then(console.log)
	.catch(console.error)
	.done();

Note this method requires node and was tested on version 5.5.0.

Namespaces

To create a Namespace within a given cluster, simply provide the namespace files within a directory matching the name of the cluster. So if you had a cluster called my-cluster, you could place the following contents into a file called ./namespaces/my-cluster/example-namespace.yaml.

apiVersion: v1
kind: Namespace
metadata:
  name: example

Manifests

All manifest files should be placed into directories corresponding to the name of the cluster + namespace they are for. So for example, if you wanted to deploy manifests to a cluster called my-cluster, you could place all the manifest files into ./manifests/my-cluster/**/*.yaml.

Supported Types

Currently we only properly support the following types to be used as manifests. Any other type used will not be deployed and will display a warning:

  • Deployment
  • Job
  • Secret
  • Service
  • DaemonSet
  • PersistentVolumeClaim

Order of Deploys (beta)

NOTE: this feature is a work in progress and may not function correctly

By default, all manifests are deployed to a given cluster at the same time. If however you require manifests to be deployed in a specific order you can utilize the "dependency-selector". By specifying a manifest with dependencies on other resources, the deployer will only deploy that manifest once those other services are fully available on the cluster.

You can specify dependencies using a metadata annotation called kit-deployer/dependency-selector. It should be a valid label selector. For example:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: proxy-deployment
  annotations:
    kit-deployer/dependency-selector: database=mongo,env=prod

Supported Dependency Types

Currently we only properly support the following types to be used as dependencies:

  • Deployment
  • Job
  • Secret
  • Service

Expected environment variables

The following environment variables are used by this service.

VariableDescriptionRequiredDefault
API_VERSIONThe kubernetes api version to useyesv1
CI_COMMIT_IDThe commit sha that we are deploying. Needed if GITHUB_ENABLED=truenoempty
SELECTORSelector (label query) to filter onnoempty
CONFIGSSet the pattern to search for cluster config filesyes/configs/**/kubeconfig
NAMESPACES_DIRSet the directory where all the namespace files are. They should be grouped in folders matching the metadata.name of the cluster that you want them deployed toyes/namespaces
MANIFESTS_DIRSet the directory where all the manifest files are. They should be grouped in folders matching the metadata.name of the cluster that you want them deployed toyes/manifests
DRY_RUNWill only show the diff and will not push anything to the clusteryestrue
IS_ROLLBACKA boolean flag that is passed in the available payload postyesfalse
DIFFWill show a diffyesfalse
FORCEWill push all changes even if there are no differencesyesfalse
AVAILABLE_ENABLEDWill check if deployed service is available, but will only affect if deployment is considered successful or not if --available-required is also enabledyesfalse
AVAILABLE_HEALTH_CHECKWill monitor for issues during the deploymentyestrue
AVAILABLE_HEALTH_CHECK_GRACE_PERIODThe amount of time in seconds that the health check will wait for a deployment to self-heal before triggering a failureyes10
AVAILABLE_WEBHOOKThe URL you want to send the status payload of the deployment progress to. You can provide multiple endpoints by using a JSON array of URLsnoempty
AVAILABLE_REQUIREDWill only finish once the manifest is considered available in the clusteryesfalse
AVAILABLE_KEEP_ALIVEWill print the status of the available check every AVAILABLE_KEEP_ALIVE_INTERVAL seconds (useful for CI tools that require log output to prevent timeouts)yesfalse
AVAILABLE_KEEP_ALIVE_INTERVALDetermines the interval at which the keep alive message will be printedyes30
AVAILABLE_TIMEOUTThe number of seconds to wait for a given manifest to be availableyes600
DEPENDENCY_WAITThe number of seconds to wait between status check attempts for a dependencyyes3
DEPENDENCY_TIMEOUTThe number of seconds to wait before timing out waiting for a dependency to be availableyes600
GITHUB_ENABLEDIf true, will check the date of the commit against github and will only deploy if the commit is newer than what is on the cluster.yestrue
GITHUB_AUTH_TOKENYour github token to the repo we are deploying (used to retrieve additional info on the commit)yesempty
GITHUB_USERThe github user that the repo belongs toyesempty
GITHUB_REPOThe github repo nameyesempty

Contributing

See the Contributing guide for steps on how to contribute to this project.

FAQs

Package last updated on 09 Aug 2016

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc