# binder-deploy-kubernetes

> A Binder backend that deploys apps onto a Kubernetes cluster

Latest version **1.1.1** (published 2016-08-22) · MIT license · 0 weekly downloads

## Install

```sh
npm install binder-deploy-kubernetes
pnpm add binder-deploy-kubernetes
yarn add binder-deploy-kubernetes
bun add binder-deploy-kubernetes
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 1.1.1 |
| Published | 2016-08-22 |
| First published | 2016-03-30 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 21 |
| Known vulnerabilities | 0 (+13 in 4 direct dependencies) |
| Install scripts | yes |
| GitHub stars | 9 |
| Author | Andrew Osheroff |
| Maintainers | andrewosh |
| Keywords | binder, module, binder-deploy-kubernetes |

## Links

- npm: https://www.npmjs.com/package/binder-deploy-kubernetes
- Repository: https://github.com/binder-project/binder-deploy-kubernetes
- Issues: https://github.com/binder-project/binder-deploy-kubernetes/issues
- npm.io page: https://npm.io/package/binder-deploy-kubernetes

## Dependencies (21)

- [hat](https://npm.io/package/hat.md) 0.0.3
- [async](https://npm.io/package/async.md) ^1.5.0
- [lodash](https://npm.io/package/lodash.md) ^4.3.0
- [moment](https://npm.io/package/moment.md) ^2.11.2
- [express](https://npm.io/package/express.md) ~4.13.3
- [request](https://npm.io/package/request.md) ~2.65.0
- [shelljs](https://npm.io/package/shelljs.md) ^0.5.3
- [inherits](https://npm.io/package/inherits.md) ^2.0.1
- [jsonfile](https://npm.io/package/jsonfile.md) ^2.2.3
- [mongoose](https://npm.io/package/mongoose.md) ^4.4.3
- [url-join](https://npm.io/package/url-join.md) 0.0.1
- [wait.for](https://npm.io/package/wait.for.md) ^0.6.6
- [binder-db](https://npm.io/package/binder-db.md) ^1.0.0
- [commander](https://npm.io/package/commander.md) ^2.9.0
- [kube-stream](https://npm.io/package/kube-stream.md) ^1.0.0
- [binder-utils](https://npm.io/package/binder-utils.md) ^1.0.0
- [binder-module](https://npm.io/package/binder-module.md) ^1.0.1
- [string-format](https://npm.io/package/string-format.md) ~0.5.0
- [binder-logging](https://npm.io/package/binder-logging.md) ^1.0.0
- [kube-test-utils](https://npm.io/package/kube-test-utils.md) ^1.0.0
- [node-kubernetes-client](https://npm.io/package/node-kubernetes-client.md) ^0.2.3

## Recent versions

- 1.1.1 (latest) — 2016-08-22
- 1.1.0 — 2016-07-11
- 1.0.20 — 2016-07-10
- 1.0.19 — 2016-07-10
- 1.0.17 — 2016-07-07
- 1.0.16 — 2016-07-07
- 1.0.15 — 2016-06-30
- 1.0.14 — 2016-06-30
- 1.0.13 — 2016-06-20
- 1.0.12 — 2016-06-20
- 1.0.11 — 2016-06-20
- 1.0.10 — 2016-06-17
- 1.0.9 — 2016-06-17
- 1.0.8 — 2016-05-11
- 1.0.6 — 2016-04-25
- … 6 more at https://npm.io/package/binder-deploy-kubernetes/versions

## README

# binder-deploy-kubernetes
A binder-deploy implementation that launches containers on a Kubernetes cluster

The [`deploy`](https://github.com/binder-project/binder-protocol/blob/master/index.js#L262) API
defines how Binder
[templates](https://github.com/binder-project/binder-build#constructing-a-template-from-an-image)
can be launched on any container management system. In our production environment, all templates
are launched on a Kubernetes cluster using this module.

By default, containers are transient and are culled after one hour of inactivity.

When containers are first deployed (through `POST`ing to `/applications/<template name>`), they
are assigned an `id` but not a `location`. Once the `location` has been assigned (generally 5-10s
after the container has been scheduled), the client can redirect to that location. After the
initial deployment command, the `location` can be determined by polling the
`/applications/<template name>/<id>` endpoint.

### install
The simplest way to run the `binder-build` server is through the
[`binder-control`](https://github.com/binder-project/binder-control) module, which manages the
server's lifecycle and service (the database and logging system) dependencies.  Additionally,
`binder-control` uses the PM2 process manager to monitor/restart the server in the event of
failures. In `binder-control`, the deploy server can be started with with custom configuration
parameters through
```
binder-control deploy-kubernetes start --api-key=<key> --config=/path/to/config
```

It will also be started with reasonable defaults through
```
binder-control start-all
```

If you'd prefer to use `binder-build` in standalone mode:
```
git clone git@github.com:binder-project/binder-deploy-kubernetes
cd binder-deploy-kubernetes
npm i && npm start
```

### api

The `deploy` portion of the Binder API consists of the following endpoints:

----------------------------

Get the status of a single deployed template with a given ID

```
GET /applications/binder-project-example-requirements/84b8f9e8d573e73016fa2c14bad86a4d HTTP 1.1
```

*returns*

```
{
  "id": "84b8f9e8d573e73016fa2c14bad86a4d",
  "template-name": "binder-project-example-requirements",
  "location": "104.197.56.211/user/84b8f9e8d573e73016fa2c14bad86a4d",
  "status": "deleted"
}
```
------------------------------

Get the status of all deployed templates for a template name

```
GET /applications/binder-project-example-requirements HTTP 1.1
Authorization: 880df8bbabdf4b48f412208938c220fe
```

*returns*

```
[
  {
    "id": "74156d847a6bc8e07c64a43aaed53514",
    "template-name": "binder-project-example-requirements",
    "location": "104.197.56.211/user/74156d847a6bc8e07c64a43aaed53514",
    "status": "deleted"
  },
  ...
  {
    "id": "880aa1c3798c32ad6fc120267e3ae610",
    "template-name": "binder-project-example-requirements",
    "location": "104.197.56.211/user/880aa1c3798c32ad6fc120267e3ae610",
    "status": "deleted"
  }
]
```
-------------------------------

Launch a new instance of a template

```
POST /applications/binder-project-example-requirements
Content-Type: application/json
```

*returns*

```
{
  "id": "a16653059942e2ef2b1c7b458d6a2463"
}
```
--------------------------------

### usage

The best way to interact with the deploy server is through the
[`binder-client`](http://github.com/binder-project/binder-client). Once the client has been
installed, all endpoints are accessible either programmatically or through the CLI. For example:

From JS
```
var binder = require('binder-client')
binder.deploy.status(<deployment options>, function (err, status) {
  ...
})
```

From the CLI
```
binder deploy status <image-name> --api-key=<key> --host=<host> --port=<port>
```

---
_Source: https://npm.io/package/binder-deploy-kubernetes · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._