Deis 0.0.7 - Bug Squash & Docker 0.6.1
The Deis project is happy to announce v0.0.7 which is primarily a bug fix release. We look forward to the next round of feature development as we push toward our 0.1.0.
What is Deis?
Deis is a Django/Celery API server, Python CLI and set of Chef cookbooks that combine to provide a Heroku-inspired application platform for public and private clouds. Your PaaS. Your Rules.
- Fixed stacktrace when user had no SSH keys
- Fix intermittent EC2 SSH timeout resulting in 404 on scale command
- Fix stacktrace and 500 error when no credentials provided
- Fix git-push error due to duplicate SSH keys being allowed on server
- Fix 404 error on 500 error due to missing Nginx HTML template
- Fix Chef error due to malformed proxy data bag
- Fix Chef warnings due to duplicate resource name for gitosis bare repo
- Update to Docker 0.6.1
- Make flavor parameters explicit and updateable so users can change AMI ID, Instance Size
- Add checks for Deis dependencies to PaaS controller provisioning script
- Retry Chef API calls to work around intermittent Hosted Chef 500 errors
- Update public EC2 AMIs to include latest security packages and components (e.g. Buildstep)
Much of the list below has been rolled over from 0.0.6. Now that we have these important bug fixes behind us, we can move forward with some necessary refactoring and the development of important new features requested by the community.
Backwards Incompatible Changes
There are a few backwards incompatible changes we need to get behind us. Firstly, we need to allow multiple applications to be hosted on a single formation with a single set of proxy and runtime nodes. This will allow Deis to meet the needs of software teams looking to cheaply host multiple dev/test applications using Docker. Secondly, we need to support layers that serve as both proxy and runtime to minimize node usage for small deployments and ultimately allow for cross-provider formations. We've made lots of progress on this front already.
Rackspace & Digital Ocean Providers
We've had many requests for a Digital Ocean provider. We are also interested in building an OpenStack-based provider for Deis. That means Rackspace and Digital Ocean will be our next supported providers. We will be using a TDD approach to help formalize the process for implementing a new provider. This is well on its way.
Acceptance Test Automation
Deis has many moving parts. In order to ensure quality from release to release we are building an end-to-end test framework based on pexpect. The test automation will include creating formations, scaling layers, deploying applications, scaling containers and more. The automation test will be available in the repository for anyone to run. See the acceptance test branch for the latest on this.
Enhanced Docker Integration
Deis currently uses Docker as a LXC wrapper for running Buildpack slugs that are bind-mounted into Buildstep images. As soon as the Docker Private Registry code stabilizes, we will be adding a new
git push build process that creates and distributes images via
Dockerfile and a private registry hosted on the controller. We will also allow builds to reference any existing Docker image by a fully qualified image URI.
Both the controller and formation proxies require SSL configuration. Right now controller sessions are just HTTP with cookies and passwords sent in the clear! Before we tackle formation SSL, we need the backwards incompatible changes to applications and proxies to land in master.
General Security Improvements
We've glossed over some pretty important security features in an effort to get Deis into developers hands sooner rather than later. For example, we need to implement iptables host-level firewalls, improve security group default rules, use Chef recipes to harden systems, etc. If you find any other security holes, please open a GitHub issue and tag it "Security".
As of now, only a single user can control or push to a formation. We need to add simple sharing features, which we can then expand upon using finer-grained access controls.
We do not currently monitor nodes or container health -- though we have infrastructure in place to do it.
We need to make it as easy for ops folks to publish a set of reusable backing services (databases, queues, storage, etc) and allow developers to attach those services to applications. This will be done in a loosely coupled way, following Twelve Factor best practices.
How can you help?
- Star our GitHub repository
- Help spread the word about @opendeis on Twitter
- Explore contributing to the Deis project by joining the #deis channel on Freenode
You can learn about other ways to get involved on our website.