Skip to content
This repository has been archived by the owner on Jun 12, 2018. It is now read-only.

Commit

Permalink
v0.4.0
Browse files Browse the repository at this point in the history
  • Loading branch information
fgrehm committed Jul 6, 2015
1 parent 6a8c9fe commit d8e3b60
Show file tree
Hide file tree
Showing 4 changed files with 21 additions and 17 deletions.
7 changes: 4 additions & 3 deletions docs/cli/commands.md
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand All @@ -53,7 +53,7 @@ By running the command from your project's root, Devstep will:

The `devstep/<PROJECT>` 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/<PROJECT>:latest`
as the base container for new "hacking sessions" so that you don't have to build
Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/cli/configuration.md
Expand Up @@ -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`
Expand Down
10 changes: 5 additions & 5 deletions docs/getting-started.md
Expand Up @@ -4,15 +4,15 @@
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.

## Sanity check
---------------

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`
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down
19 changes: 11 additions & 8 deletions docs/introduction.md
Expand Up @@ -25,28 +25,31 @@ 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.


## 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"
Expand Down

0 comments on commit d8e3b60

Please sign in to comment.