Deis 0.0.6 - Log Aggregation, Admin Commands and More
The Deis project is proud to announce our 0.0.6 release which includes some important new features such as log aggregation and one-off admin commands and lots of bug fixes.
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.
deis logs: automatic aggregation of Docker container logs using rsyslog
deis run <command>: run one-off commands inside ephemeral Docker containers
deis open: open your application in your default browser
- Documentation search now available at http://docs.deis.io/
- Fixed environment issue with controller provisioning script
- Fixed accidental converge and orphaned DB record after scaling down a layer
- Fixed bug where multiple user accounts broke formation management
- Fixed bug with cookie handling during registration and login
- Fixed stack trace on missing provider credentials
- Fixed 500 errors on missing log data
- Fixed buildpack breakage due to Docker DNS issue
- 500 errors now log full stack traces to
/var/log/deis/server.logfor easy reporting
- Deis controller recipes unified into single recipe[deis::controller]
- Updated to latest Django (1.5.2), Django REST Framework, South and Boto libraries
- Django admin interface enabled for easy database model access
- New text-based progress indicator on command line client
- Improved developer setup documentation
Community Shout Outs
We'd like to thank the following users for reporting issues via GitHub:
- @zbyte64 - Python buildpack breaks when fetching python runtime
- @jwmarshall - ec2 provision script should use /bin/bash instead of /bin/sh
- @aaronlifton problem with initial deploy
- @ianthedeveloper, @zodman, @BrianHicks - Implement Digital Ocean provider and flavors
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 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.
Rackspace & Digital Ocean Providers
We've had many requests for a Digital Ocean provider. We also need to build 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.
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 auomation 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.
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.