From d8e3b604fa34b0a2f9db6ef64401f54ce806b711 Mon Sep 17 00:00:00 2001 From: Fabio Rehm Date: Mon, 6 Jul 2015 16:52:22 -0300 Subject: [PATCH] v0.4.0 --- docs/cli/commands.md | 7 ++++--- docs/cli/configuration.md | 2 +- docs/getting-started.md | 10 +++++----- docs/introduction.md | 19 +++++++++++-------- 4 files changed, 21 insertions(+), 17 deletions(-) diff --git a/docs/cli/commands.md b/docs/cli/commands.md index b874ae0..ad281ef 100644 --- a/docs/cli/commands.md +++ b/docs/cli/commands.md @@ -15,7 +15,7 @@ This is the easiest way to get started with Devstep. By running the command from your project's root, Devstep will: -1. Create a Docker container based on `fgrehm/devstep:v0.3.1` with project +1. Create a Docker container based on `fgrehm/devstep:v0.4.0` with project sources bind mounted at `/workspace`. 2. Detect and install project's dependencies on the new container using the available buildpacks. @@ -44,7 +44,7 @@ devstep hack -p 80:8080 --link postgres:db --link memcached:mc -e DEVSTEP_BUNDLE By running the command from your project's root, Devstep will: -1. Create a Docker container based on `fgrehm/devstep:v0.3.1` with project +1. Create a Docker container based on `fgrehm/devstep:v0.4.0` with project sources bind mounted at `/workspace`. 2. Detect and install project's dependencies on the new container using the available buildpacks. @@ -53,7 +53,7 @@ By running the command from your project's root, Devstep will: The `devstep/` images act like snapshots of your project dependencies and will be used as the source image for subsequent `devstep` commands instead -of the `fgrehm/devstep:v0.3.1` image. +of the `fgrehm/devstep:v0.4.0` image. For example, running a `devstep hack` after building the image will use `devstep/:latest` as the base container for new "hacking sessions" so that you don't have to build @@ -128,6 +128,7 @@ of choice. * `info` - Show information about the current environment * `run` - Run a one off command against the current base image +* `exec` - Run a one off command against the last container created for the current project * `binstubs` - Generate binstubs for the commands specified on devstep.yml * `clean` - Remove previously built images for the current environment * `pristine` - Rebuild project image from scratch diff --git a/docs/cli/configuration.md b/docs/cli/configuration.md index 2471608..246ada9 100644 --- a/docs/cli/configuration.md +++ b/docs/cli/configuration.md @@ -12,7 +12,7 @@ The available options are described below: repository: 'repo/name' # The image used by devstep when building environments from scratch -# DEFAULT: 'fgrehm/devstep:v0.3.1' +# DEFAULT: 'fgrehm/devstep:v0.4.0' source_image: 'source/image:tag' # The host cache dir that gets mounted inside the container at `/home/devstep/cache` diff --git a/docs/getting-started.md b/docs/getting-started.md index 9375cb3..81f3854 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -4,7 +4,7 @@ Devstep comes in two flavors, you can either use the provided CLI or you can build on top of the provided images from `Dockerfile`s. -Regardless of the flavor you choose, it is a good idea to `docker pull fgrehm/devstep:v0.3.1` +Regardless of the flavor you choose, it is a good idea to `docker pull fgrehm/devstep:v0.4.0` before creating your first container / image for a better user experience. Docker will download that image as needed when using `Dockerfile`s but the Devstep CLI won't. @@ -12,7 +12,7 @@ will download that image as needed when using `Dockerfile`s but the Devstep CLI --------------- This project is being developed and tested on an Ubuntu 14.04 host with Docker -1.4.0+, while it is likely to work on other distros / Docker versions / +1.7.0, while it is likely to work on other distros / Docker versions / [boot2docker](http://boot2docker.io/), I'm not sure how it will behave on the wild. Please note that the CLI is currently limited to connecting to a local `/var/run/docker.sock` @@ -38,10 +38,10 @@ line to your `~/devstep.yml` so that the image is used as a source for your proj To install the CLI, you can run the one liner below and read on for more: ```sh -L=$HOME/bin/devstep && curl -sL https://github.com/fgrehm/devstep-cli/releases/download/v0.3.1/linux_amd64 > $L && chmod +x $L +L=$HOME/bin/devstep && curl -sL https://github.com/fgrehm/devstep-cli/releases/download/v0.4.0/linux_amd64 > $L && chmod +x $L ``` -_The snippet above assumes `$HOME/bin` is on your PATH, change `$HOME/bin` to +_The snippet above assumes `$HOME/bin` is on your `PATH`, change `$HOME/bin` to an appropriate path in case your system is not configured like that._ ### Doing a quick hack on a project @@ -180,7 +180,7 @@ The `fgrehm/devstep` image is the base image used for Devstep environments and requires you to manually trigger the build: ```Dockerfile -FROM fgrehm/devstep:v0.3.1 +FROM fgrehm/devstep:v0.4.0 # Add project to the image and build it ADD . /workspace diff --git a/docs/introduction.md b/docs/introduction.md index b97851c..5b1359f 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -25,10 +25,11 @@ is not an easy task for many people. Yes, there are plenty of platform specific images available for download on [Docker Hub](https://hub.docker.com/) but because Devstep's base image provides an environment that is [similar to Heroku's](https://github.com/progrium/cedarish), it should be capable of building and running a wide range of applications / tools -/ libraries from a single image. +/ libraries from a single image without the need to worry about writing `Dockerfile`s. -Devstep is also capable of reducing the disk space and initial configuration times by -(optionally) caching packages on the host machine using a strategy similar to [vagrant-cachier's cache buckets](http://fgrehm.viewdocs.io/vagrant-cachier/how-does-it-work), +With Devstep's CLI, we can also reduce the disk space and initial configuration +times by (optionally) caching packages on the host machine using a strategy similar +to [vagrant-cachier's cache buckets](http://fgrehm.viewdocs.io/vagrant-cachier/how-does-it-work), where project dependencies packages are kept on the host while its contents are extracted inside the container. @@ -36,17 +37,19 @@ extracted inside the container. ## Usage Devstep can be used to build development environments in at least two different -ways: from the provided Golang CLI or from `Dockerfile`s. To run the images built, -you can use the provided `devstep hack` command, use other tools (like [docker-compose](http://docs.docker.com/compose/)) +ways: from the provided CLI or from `Dockerfile`s. To run the images built, you +can use the provided `devstep hack` command, use other tools (like [docker-compose](http://docs.docker.com/compose/)) or just `docker run` them by hand. ## What's included on the base [Docker image](https://registry.hub.docker.com/u/fgrehm/devstep/)? -That image is based on [`progrium/cedarish:cedar14`](https://github.com/progrium/cedarish), -so everything that gets installed by it will be available for `fgrehm/devstep` images. +That image is based on [Heroku's `cedar:14` image](https://registry.hub.docker.com/u/heroku/cedar/) +which makes up for the [Cedar-14](https://devcenter.heroku.com/articles/cedar) +stack. So everything that is available to it (and as a consequence, available to +Heroku apps) will be available for `fgrehm/devstep` environments. -On top of `progrium/cedarish:cedar14`, we: +On top of `heroku/cedar:14`, we: * Create a `developer` user to avoid using `root` and creating files with wrong permissions during development. * Install some extra devel packages (like `libyaml-dev`) and other "nice to have"