Releases: infolinks/deployster
16.2.1
16.2.0
16.1.0
Pull resource images proactively and TTY improvements (#8)
Pull resource Docker images proactively during bootstrap phase.
Improve handling of TTY errors, and update deployster.sh
to automatically detect when its running in a terminal (or not) and invoke the docker run
command appropiately (send -it
or not).
16.0.2
16.0.1
16.0.0
Resources refactor (#5)
Deployster Resources implementation refactor.
Simplified significantly the resources directory structure as well as its Docker image hierarchy. Resource Docker images are now laid out flat under the "resources" directory, and all their Python source code
reside under a single root at "resources/src".
This enables sharing code much more easily and especially enabled moving the resources source code into an object-oriented structure, where each resource is actually a Python class.
Resource classes extend a common "DResource" class that provides the struts of the resource workflow. It's important to note that all of this is non-binding! One can still write a resource image completely separate from this foundation, and manually implement the resource workflow via Ruby or Bash or any other means, since the protocol between Deployster and the resource images was and remains the Docker entrypoint & arguments.
This refactor also introduces new resources:
- RBAC cluster role & binding
- RBAC namespaced role & binding
Those kind-of existed before but were not fully implemented. They still aren't, but are more nearer to that goal.
15.0.0
v14.0.0
v13
Changes in this release:
Commit | Change |
---|---|
1a267ab | @arikkfir: add "--skip-gdm" and "--skip-project-setup" flags: - the "--skip-gdm" flag will make deployster skip Google Deployment Manager deployments - the "--skip-project-setup" will make deployster assume that the project exists, and has already been set up (permissions, billing, APIs, etc) |
1d724a7 | @arikkfir: reorder instructions in Dockerfile to first install dependencies and after that add our files; logic is that if source code changes, no need to invalidate the layers with our dependencies. |
36e67f7 | @arikkfir: remove support for the 'kubernetes/security' (move it to 'kube-system') and expect 'kube-system' resources in the 'kube-system' directory (no more just 'system'...) |