3 releases
Uses old Rust 2015
0.2.2 | Mar 23, 2017 |
---|---|
0.2.1 | Mar 22, 2017 |
0.2.0 | Mar 22, 2017 |
#572 in Unix APIs
13KB
251 lines
Persistent Isolated Development Environments
Use docker to create fully persistent and isolated development environments. Think virtualenv
from the python world, only for a whole system.
Installation
If you have rust + cargo installed: cargo install pide-rs
.
Binaries coming soon.
Dependencies
- docker (tested with v17.03)
Usage
First, create a dockerfile somewhere like ~/dockerfiles/debian-jessie-vim
. The contents should look something like this:
FROM debian:jessie
RUN apt-get update
RUN apt-get install -y \
vim
Next, move to the working directory of your project. Here I will use ~/demo
. Initialize pide
to your local working directory. This step may take some time, depending on how long it takes to build your dockerfile for the first time.
~ cd ~/demo
~ pide init ~/dockerfiles/debian-jessie-vim
Building dockerfile (if necessary)...
Initialized pidefile
Now you have a persistent working environment! jump into it by calling pide resume
.
~ ls -a
. .. a.txt b.txt c.txt .pide
~ pide resume
Running `debian-jessie-vim` for the first time...
root@ae6da64ee5e2:/# ls /host
a.txt b.txt c.txt
root@ae6da64ee5e2:/# echo Hello World > hello_file
root@ae6da64ee5e2:/# cat hello_file
Hello World
root@ae6da64ee5e2:/# exit
Committing container history...
Note that the location you call pide resume
from is mapped as /host
in the docker environment. This is dangerous and bad. Be careful with this.
In this example, we created a file called hello_file
. If we resume again, it will still be there! This is also true for any system changes made, for example installing packages. Lets see what happens when we run it again:
~ pide resume
Resuming `debian-jessie-vim` where you left off...
root@9691f706c0e5:/# ls -l | grep hello_file
-rw-r--r-- 1 root root 12 Mar 19 18:39 hello_file
Multiple Instances
If you re-use the same dockerfile in separate places, they will not interact with each other (though the init
stage will run much faster, as the original cached docker image is used). Example:
~ mkdir demo2
~ cd demo2
~ pide init ~/dockerfiles/debian-jessie-vim
Building dockerfile (if necessary)...
Initialized pidefile
~ pide resume
Running `debian-jessie-vim` for the first time...
root@b64b1d8e24da:/# ls
bin boot dev etc home host lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
root@b64b1d8e24da:/# exit
Committing container history...
~
Using multiple dockerfiles in one working directory is not currently supported.
TODOs, Notes, Other
First of all, this is a really hacky tool meant to support my workflow. It should NOT be used for production, and may misbehave in any number of unsafe or dangerous ways. Use at your own risk.
Known issues/problems
- This will create a lot of orphaned docker images. This generally wastes space on your machine. From docker v1.13+, you can run
docker system prune
to clean up a bit. This is a bigger problem on Mac/Windows, where docker runs within a virtual machine with fairly limited total space. In those environments, I suggest using vagrant instead of this tool (you're running a VM anyway) - This tool maps your current working directory to docker. The root user can then do all sorts of bad things with UID 0, including making things executable, deleting the mapped directory, etc. Assume anything you do inside docker could have impact outside of docker. Use this only for dependency isolation, NOT security isolation
- Basically nothing is configurable yet. Eventually I would like to support more functionality from tools like
docker-compose
to map ports, volumes, networks, etc.
License
This tool is licensed under the MIT license.
Dependencies
~4.5MB
~80K SLoC