| web: | |
| build: | |
| image: username/my-app | |
| dockerfile: Dockerfile | |
| links: | |
| - redis | |
| - postgres | |
| redis: | |
| image: redis:3.2 | |
| postgres: |
--cache-test and building an image from a cache source that does not have a local parent chain.cache-test $ docker pull rheinwein/cache-test
Using default tag: latest
latest: Pulling from rheinwein/cache-test
557a0c95bfcd: Pull complete
98a89d507c56: Pull complete
When preserving the parent/child layer relationship via docker save and docker load, all layers of the image must be saved together, including the base image.
Note: if an image is tagged, you can use the tag name in place of the image ID.
I'm using Docker 1.12-rc2. Behavior may vary on pre-1.10 versions.
This is because the bottom layer of the customer image does not receive the parent ID when being saved. When it's loaded, Docker doesn't know that the two images belong together. A subsequent docker build will show the base image being used, but there is no available cache because of the missing link between customer and base image. In the image rebuild output, notice there is no using cache output.
cache-test $ docker build -t cache-test .
| [{ | |
| "id": 3277309, | |
| "uuid": "80240b80-6742-0132-8d88-366b9ffd5919", | |
| "project_id": 33837, | |
| "status": "success", | |
| "branch": "master", | |
| "commit_id": "81d2282b97c37c30a40302282404f4ee2828f61f", | |
| "github_username": "beanieboi", | |
| "message": "Landjaeger sausage pork belly spare ribs, ham hock.", | |
| "started_at": "2015-12-16T11:13:35.178Z", |
#Ruby Open Source Projects for ROSSConf
##Flatcar https://github.com/flatcar/flatcar
Clone the repo, then point bundler to your branch in the Gemfile. Run bundle install and then you're ready to test the gem by running it within the context of bundler to avoid conflicts -- bundle exec bin/flatcar.
Flatcar is tested with rspec, and you can find a test coverage report via simplecov-rcov.
##Lorry https://github.com/CenturyLinkLabs/lorry (the API)
I hereby claim:
To claim this, I am signing this object:
Much of the focus of Docker is on the process of packaging and running your application in an isolated container. There are countless tutorials that explain how to run your application in a Docker container, but very few that discuss how properly stop your containerized app. That may seem like a silly topic -- who cares how you stop a container, right?
Well, depending on your application, the process by which you stop your app could be very important. If your application is serving HTTP requests you may want to complete any outstanding requests before you shutdown your container. If your application writes to a file, you probably want to ensure that the data is properly flushed and the file is closed before your container exits.
Things would be easy if you simply started a container and it ran forever, but there's a good chance that your application will need to be stopped and restarted at some point to facilitate an upgrade or a migration to another host. For those times when you need to stop a run
ImageLayers.io is a new project from the team at CenturyLink Labs. This utility provides a browser-based visualization of user-specified Docker Images and their layers. This visualization provides key information on the composition of a Docker Image and any commonalities between them. ImageLayers.io allows Docker users to easily discover best practices for image construction, and aid in determining which images are most appropriate for their specific use cases.
##What are Layers? Docker uses a union filesystem for managing images. Each layer of an image is the result of some action taken during the build. This could be installing a package, copying files from a local or remote source, or setting an environment variable. Each action creates a new l
ImageLayers.io is a new project from the team at CenturyLink Labs. This utility provides a visualization in the browser of user-specified Docker Images and their layers. This visualization provides key information on the composition of a Docker Image and any commonalities between them. ImageLayers.io allows Docker users to easily discover best practices for image construction, and aid in determining which images are most appropriate to use in their specific use cases.
##What are Layers? Docker uses a union file system for managing images. Each layer of your image is the result of some action taken during the build. This could be installing a package, copying files from a local or remote source, or setting an environment variable. Each action creates a new layer in the file system; layers reference their parents and are cached, so they may be used as a part of an entirely different image.
There is a direct correlation between your Dockerfile and the number of layers in your image. Docker offers some advice o
##mailinglists
##list of speakers
