dksnap creates, views, and runs snapshots of Docker containers.
When testing locally we often use containers with test data. dksnap allows you to snapshot those containers at a good state, and roll back or forward as needed.
Install on MacOS or Linux:
curl https://kelda.io/install-dksnap.sh | sh
Or download the latest release and
copy to your path.
# Download the demo. git clone https://github.com/kelda/dksnap.git cd dksnap/demo # Start the example application. You can access it in your browser at localhost:8080. docker-compose up -d # Use dksnap to create snapshots of the entries in the Mongo database. dksnap
Create a snapshot of any running Docker container.
dksnap works with any
container, but has extra features for select databases.
- Snapshots are volume aware. They will capture data in volumes as well as in
the container image.
- Snapshots are database aware. When snapshotting databases that implement the
dksnapwill politely ask the
database process to dump its contents before creating a Docker image.
dksnap includes a terminal browser that provides a tree view of all your
snapshots along with diffs showing how they've changed over time.
Replace Running Containers
Replace a running Docker container with a snapshot taken in the past.
will automatically shut down the running container, boot the snapshot image,
and restart the container using the same Docker command arguments.
Works With Any Container
dksnap creates snapshots by committing the container's
docker commit, and dumping the contents of all attached
dksnap is database aware, meaning it knows how to politely dump and
restore and diff database contents for the following databases:
It has a plugin architecture making it easy to add more databases in the
future. Contributions welcome!
dksnap images are simply
docker images with some additional metadata. This
means they can be viewed and manipulated using the standard
dksnap stores all of the snapshot information in a
docker image, so you can
share your snapshot by pushing it to a Docker registry just like you would any
other container image.
Snapshots are volume aware. The official database images all store their data
in volumes which
docker commit does not capture.
dksnap saves volumes in
addition to the container filesystem.
How is this different than
docker commit for its generic snapshot approach to capture the
container’s filesystem. However,
docker commit has distinct limitations:
- It doesn't capture volumes, so it can't be used with most database docker
- It isn't database aware. It doesn't politely save/restore database state
meaning it's prone to creating corrupted database images.
How is this different than a Docker image?
dksnap uses Docker images as the storage format for its snapshots, which
makes them fully compatible with all of the things you would normally do with
an image (run, push, delete, etc). You could handcraft Docker images to mimic
dksnap snapshots, but
dksnap makes it easy to create them from running
- Automated snapshot creation from production and staging databases in CI.
- A non-graphical CLI interface that's scriptable.
- Native support for additional databases.
- Snapshot of CPU and RAM state.
dksnap is still in alpha and under heavy development. Contributions are very
much welcome so please get involved. Check out the contribution
guidelines to get started.
dksnap requires being built with
go version 1.13 or later.
It uses Go Modules, and error wrapping.
git clone https://github.com/kelda/dksnap cd dksnap GO111MODULE=on go build . ./dksnap