mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
translated
This commit is contained in:
geekpi
parent
792215d26b
commit
4246954719
@ -1,460 +0,0 @@
|
|||||||
translating---geekpi
|
|
||||||
|
|
||||||
Part 5 - LXD 2.0: Image management
|
|
||||||
==================================
|
|
||||||
This is the fifth blog post [in this series about LXD 2.0][0].
|
|
||||||
|
|
||||||
As there are a lot of commands involved with managing LXD containers, this post is rather long. If you’d instead prefer a quick step-by-step tour of those same commands, you can [try our online demo instead][1]!
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### Container images
|
|
||||||
|
|
||||||
If you’ve used LXC before, you probably remember those LXC “templates”, basically shell scripts that spit out a container filesystem and a bit of configuration.
|
|
||||||
|
|
||||||
Most templates generate the filesystem by doing a full distribution bootstrapping on your local machine. This may take quite a while, won’t work for all distributions and may require significant network bandwidth.
|
|
||||||
|
|
||||||
Back in LXC 1.0, I wrote a “download” template which would allow users to download pre-packaged container images, generated on a central server from the usual template scripts and then heavily compressed, signed and distributed over https. A lot of our users switched from the old style container generation to using this new, much faster and much more reliable method of creating a container.
|
|
||||||
|
|
||||||
With LXD, we’re taking this one step further by being all-in on the image based workflow. All containers are created from an image and we have advanced image caching and pre-loading support in LXD to keep the image store up to date.
|
|
||||||
|
|
||||||
### Interacting with LXD images
|
|
||||||
|
|
||||||
Before digging deeper into the image format, lets quickly go through what LXD lets you do with those images.
|
|
||||||
|
|
||||||
#### Transparently importing images
|
|
||||||
|
|
||||||
All containers are created from an image. The image may have come from a remote image server and have been pulled using its full hash, short hash or an alias, but in the end, every LXD container is created from a local image.
|
|
||||||
|
|
||||||
Here are a few examples:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc launch ubuntu:14.04 c1
|
|
||||||
lxc launch ubuntu:75182b1241be475a64e68a518ce853e800e9b50397d2f152816c24f038c94d6e c2
|
|
||||||
lxc launch ubuntu:75182b1241be c3
|
|
||||||
```
|
|
||||||
|
|
||||||
All of those refer to the same remote image (at the time of this writing), the first time one of those is run, the remote image will be imported in the local LXD image store as a cached image, then the container will be created from it.
|
|
||||||
|
|
||||||
The next time one of those commands are run, LXD will only check that the image is still up to date (when not referring to it by its fingerprint), if it is, it will create the container without downloading anything.
|
|
||||||
|
|
||||||
Now that the image is cached in the local image store, you can also just start it from there without even checking if it’s up to date:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc launch 75182b1241be c4
|
|
||||||
```
|
|
||||||
|
|
||||||
And lastly, if you have your own local image under the name “myimage”, you can just do:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc launch my-image c5
|
|
||||||
```
|
|
||||||
|
|
||||||
If you want to change some of that automatic caching and expiration behavior, there are instructions in an earlier post in this series.
|
|
||||||
|
|
||||||
#### Manually importing images
|
|
||||||
|
|
||||||
##### Copying from an image server
|
|
||||||
|
|
||||||
If you want to copy some remote image into your local image store but not immediately create a container from it, you can use the “lxc image copy” command. It also lets you tweak some of the image flags, for example:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image copy ubuntu:14.04 local:
|
|
||||||
```
|
|
||||||
|
|
||||||
This simply copies the remote image into the local image store.
|
|
||||||
|
|
||||||
If you want to be able to refer to your copy of the image by something easier to remember than its fingerprint, you can add an alias at the time of the copy:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image copy ubuntu:12.04 local: --alias old-ubuntu
|
|
||||||
lxc launch old-ubuntu c6
|
|
||||||
```
|
|
||||||
|
|
||||||
And if you would rather just use the aliases that were set on the source server, you can ask LXD to copy the for you:
|
|
||||||
|
|
||||||
lxc image copy ubuntu:15.10 local: --copy-aliases
|
|
||||||
lxc launch 15.10 c7
|
|
||||||
All of the copies above were one-shot copy, so copying the current version of the remote image into the local image store. If you want to have LXD keep the image up to date, as it does for the ones stored in its cache, you need to request it with the `–auto-update` flag:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image copy images:gentoo/current/amd64 local: --alias gentoo --auto-update
|
|
||||||
```
|
|
||||||
|
|
||||||
##### Importing a tarball
|
|
||||||
|
|
||||||
If someone provides you with a LXD image as a single tarball, you can import it with:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image import <tarball>
|
|
||||||
```
|
|
||||||
|
|
||||||
If you want to set an alias at import time, you can do it with:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image import <tarball> --alias random-image
|
|
||||||
```
|
|
||||||
|
|
||||||
Now if you were provided with two tarballs, identify which contains the LXD metadata. Usually the tarball name gives it away, if not, pick the smallest of the two, metadata tarballs are tiny. Then import them both together with:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image import <metadata tarball> <rootfs tarball>
|
|
||||||
```
|
|
||||||
|
|
||||||
##### Importing from a URL
|
|
||||||
|
|
||||||
“lxc image import” also works with some special URLs. If you have an https web server which serves a path with the LXD-Image-URL and LXD-Image-Hash headers set, then LXD will pull that image into its image store.
|
|
||||||
|
|
||||||
For example you can do:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image import https://dl.stgraber.org/lxd --alias busybox-amd64
|
|
||||||
```
|
|
||||||
|
|
||||||
When pulling the image, LXD also sets some headers which the remote server could check to return an appropriate image. Those are LXD-Server-Architectures and LXD-Server-Version.
|
|
||||||
|
|
||||||
This is meant as a poor man’s image server. It can be made to work with any static web server and provides a user friendly way to import your image.
|
|
||||||
|
|
||||||
#### Managing the local image store
|
|
||||||
|
|
||||||
Now that we have a bunch of images in our local image store, lets see what we can do with them. We’ve already covered the most obvious, creating containers from them but there are a few more things you can do with the local image store.
|
|
||||||
|
|
||||||
##### Listing images
|
|
||||||
|
|
||||||
To get a list of all images in the store, just run “lxc image list”:
|
|
||||||
|
|
||||||
```
|
|
||||||
stgraber@dakara:~$ lxc image list
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| alpine-32 | 6d9c131efab3 | yes | Alpine edge (i386) (20160329_23:52) | i686 | 2.50MB | Mar 30, 2016 at 4:36am (UTC) |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| busybox-amd64 | 74186c79ca2f | no | Busybox x86_64 | x86_64 | 0.79MB | Mar 30, 2016 at 4:33am (UTC) |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| gentoo | 1a134c5951e0 | no | Gentoo current (amd64) (20160329_14:12) | x86_64 | 232.50MB | Mar 30, 2016 at 4:34am (UTC) |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| my-image | c9b6e738fae7 | no | Scientific Linux 6 x86_64 (default) (20160215_02:36) | x86_64 | 625.34MB | Mar 2, 2016 at 4:56am (UTC) |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| old-ubuntu | 4d558b08f22f | no | ubuntu 12.04 LTS amd64 (release) (20160315) | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| w (11 more) | d3703a994910 | no | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| | 75182b1241be | no | ubuntu 14.04 LTS amd64 (release) (20160314) | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |
|
|
||||||
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
|
||||||
```
|
|
||||||
|
|
||||||
You can filter based on the alias or fingerprint simply by doing:
|
|
||||||
|
|
||||||
```
|
|
||||||
stgraber@dakara:~$ lxc image list amd64
|
|
||||||
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
|
||||||
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
|
|
||||||
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
|
||||||
| busybox-amd64 | 74186c79ca2f | no | Busybox x86_64 | x86_64 | 0.79MB | Mar 30, 2016 at 4:33am (UTC) |
|
|
||||||
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
|
||||||
| w (11 more) | d3703a994910 | no | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|
|
||||||
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
|
||||||
```
|
|
||||||
|
|
||||||
Or by specifying a key=value filter of image properties:
|
|
||||||
|
|
||||||
```
|
|
||||||
stgraber@dakara:~$ lxc image list os=ubuntu
|
|
||||||
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
|
|
||||||
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| old-ubuntu | 4d558b08f22f | no | ubuntu 12.04 LTS amd64 (release) (20160315) | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
|
|
||||||
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| w (11 more) | d3703a994910 | no | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|
|
||||||
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
|
||||||
| | 75182b1241be | no | ubuntu 14.04 LTS amd64 (release) (20160314) | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |
|
|
||||||
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
|
||||||
```
|
|
||||||
|
|
||||||
To see everything LXD knows about a given image, you can use “lxc image info”:
|
|
||||||
|
|
||||||
```
|
|
||||||
stgraber@castiana:~$ lxc image info ubuntu
|
|
||||||
Fingerprint: e8a33ec326ae7dd02331bd72f5d22181ba25401480b8e733c247da5950a7d084
|
|
||||||
Size: 139.43MB
|
|
||||||
Architecture: i686
|
|
||||||
Public: no
|
|
||||||
Timestamps:
|
|
||||||
Created: 2016/03/15 00:00 UTC
|
|
||||||
Uploaded: 2016/03/16 05:50 UTC
|
|
||||||
Expires: 2017/04/26 00:00 UTC
|
|
||||||
Properties:
|
|
||||||
version: 12.04
|
|
||||||
aliases: 12.04,p,precise
|
|
||||||
architecture: i386
|
|
||||||
description: ubuntu 12.04 LTS i386 (release) (20160315)
|
|
||||||
label: release
|
|
||||||
os: ubuntu
|
|
||||||
release: precise
|
|
||||||
serial: 20160315
|
|
||||||
Aliases:
|
|
||||||
- ubuntu
|
|
||||||
Auto update: enabled
|
|
||||||
Source:
|
|
||||||
Server: https://cloud-images.ubuntu.com/releases
|
|
||||||
Protocol: simplestreams
|
|
||||||
Alias: precise/i386
|
|
||||||
```
|
|
||||||
|
|
||||||
##### Editing images
|
|
||||||
|
|
||||||
A convenient way to edit image properties and some of the flags is to use:
|
|
||||||
|
|
||||||
lxc image edit <alias or fingerprint>
|
|
||||||
This opens up your default text editor with something like this:
|
|
||||||
|
|
||||||
autoupdate: true
|
|
||||||
properties:
|
|
||||||
aliases: 14.04,default,lts,t,trusty
|
|
||||||
architecture: amd64
|
|
||||||
description: ubuntu 14.04 LTS amd64 (release) (20160314)
|
|
||||||
label: release
|
|
||||||
os: ubuntu
|
|
||||||
release: trusty
|
|
||||||
serial: "20160314"
|
|
||||||
version: "14.04"
|
|
||||||
public: false
|
|
||||||
You can change any property you want, turn auto-update on and off or mark an image as publicly available (more on that later).
|
|
||||||
|
|
||||||
##### Deleting images
|
|
||||||
|
|
||||||
Remove an image is a simple matter of running:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc image delete <alias or fingerprint>
|
|
||||||
```
|
|
||||||
|
|
||||||
Note that you don’t have to remove cached entries, those will automatically be removed by LXD after they expire (by default, after 10 days since they were last used).
|
|
||||||
|
|
||||||
##### Exporting images
|
|
||||||
|
|
||||||
If you want to get image tarballs from images currently in your image store, you can use “lxc image export”, like:
|
|
||||||
|
|
||||||
```
|
|
||||||
stgraber@dakara:~$ lxc image export old-ubuntu .
|
|
||||||
Output is in .
|
|
||||||
stgraber@dakara:~$ ls -lh *.tar.xz
|
|
||||||
-rw------- 1 stgraber domain admins 656 Mar 30 00:55 meta-ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz
|
|
||||||
-rw------- 1 stgraber domain admins 156M Mar 30 00:55 ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Image formats
|
|
||||||
|
|
||||||
LXD right now supports two image layouts, unified or split. Both of those are effectively LXD-specific though the latter makes it easier to re-use the filesystem with other container or virtual machine runtimes.
|
|
||||||
|
|
||||||
LXD being solely focused on system containers, doesn’t support any of the application container “standard” image formats out there, nor do we plan to.
|
|
||||||
|
|
||||||
Our images are pretty simple, they’re made of a container filesystem, a metadata file describing things like when the image was made, when it expires, what architecture its for, … and optionally a bunch of file templates.
|
|
||||||
|
|
||||||
See this document for up to date details on the [image format][1].
|
|
||||||
|
|
||||||
##### Unified image (single tarball)
|
|
||||||
|
|
||||||
The unified image format is what LXD uses when generating images itself. They are a single big tarball, containing the container filesystem inside a “rootfs” directory, have the metadata.yaml file at the root of the tarball and any template goes into a “templates” directory.
|
|
||||||
|
|
||||||
Any compression (or none at all) can be used for that tarball. The image hash is the sha256 of the resulting compressed tarball.
|
|
||||||
|
|
||||||
##### Split image (two tarballs)
|
|
||||||
|
|
||||||
This format is most commonly used by anyone rolling their own images and who already have a compressed filesystem tarball.
|
|
||||||
|
|
||||||
They are made of two distinct tarball, the first contains just the metadata bits that LXD uses, so the metadata.yaml file at the root and any template in the “templates” directory.
|
|
||||||
|
|
||||||
The second tarball contains only the container filesystem directly at its root. Most distributions already produce such tarballs as they are common for bootstrapping new machines. This image format allows re-using them unmodified.
|
|
||||||
|
|
||||||
Any compression (or none at all) can be used for either tarball, they can absolutely use different compression algorithms. The image hash is the sha256 of the concatenation of the metadata and rootfs tarballs.
|
|
||||||
|
|
||||||
##### Image metadata
|
|
||||||
|
|
||||||
A typical metadata.yaml file looks something like:
|
|
||||||
|
|
||||||
```
|
|
||||||
architecture: "i686"
|
|
||||||
creation_date: 1458040200
|
|
||||||
properties:
|
|
||||||
architecture: "i686"
|
|
||||||
description: "Ubuntu 12.04 LTS server (20160315)"
|
|
||||||
os: "ubuntu"
|
|
||||||
release: "precise"
|
|
||||||
templates:
|
|
||||||
/var/lib/cloud/seed/nocloud-net/meta-data:
|
|
||||||
when:
|
|
||||||
- start
|
|
||||||
template: cloud-init-meta.tpl
|
|
||||||
/var/lib/cloud/seed/nocloud-net/user-data:
|
|
||||||
when:
|
|
||||||
- start
|
|
||||||
template: cloud-init-user.tpl
|
|
||||||
properties:
|
|
||||||
default: |
|
|
||||||
#cloud-config
|
|
||||||
{}
|
|
||||||
/var/lib/cloud/seed/nocloud-net/vendor-data:
|
|
||||||
when:
|
|
||||||
- start
|
|
||||||
template: cloud-init-vendor.tpl
|
|
||||||
properties:
|
|
||||||
default: |
|
|
||||||
#cloud-config
|
|
||||||
{}
|
|
||||||
/etc/init/console.override:
|
|
||||||
when:
|
|
||||||
- create
|
|
||||||
template: upstart-override.tpl
|
|
||||||
/etc/init/tty1.override:
|
|
||||||
when:
|
|
||||||
- create
|
|
||||||
template: upstart-override.tpl
|
|
||||||
/etc/init/tty2.override:
|
|
||||||
when:
|
|
||||||
- create
|
|
||||||
template: upstart-override.tpl
|
|
||||||
/etc/init/tty3.override:
|
|
||||||
when:
|
|
||||||
- create
|
|
||||||
template: upstart-override.tpl
|
|
||||||
/etc/init/tty4.override:
|
|
||||||
when:
|
|
||||||
- create
|
|
||||||
template: upstart-override.tpl
|
|
||||||
```
|
|
||||||
|
|
||||||
##### Properties
|
|
||||||
|
|
||||||
The two only mandatory fields are the creation date (UNIX EPOCH) and the architecture. Everything else can be left unset and the image will import fine.
|
|
||||||
|
|
||||||
The extra properties are mainly there to help the user figure out what the image is about. The “description” property for example is what’s visible in “lxc image list”. The other properties can be used by the user to search for specific images using key/value search.
|
|
||||||
|
|
||||||
Those properties can then be edited by the user through “lxc image edit” in contrast, the creation date and architecture fields are immutable.
|
|
||||||
|
|
||||||
##### Templates
|
|
||||||
|
|
||||||
The template mechanism allows for some files in the container to be generated or re-generated at some point in the container lifecycle.
|
|
||||||
|
|
||||||
We use the pongo2 templating engine for those and we export just about everything we know about the container to the template. That way you can have custom images which use user-defined container properties or normal LXD properties to change the content of some specific files.
|
|
||||||
|
|
||||||
As you can see in the example above, we’re using those in Ubuntu to seed cloud-init and to turn off some init scripts.
|
|
||||||
|
|
||||||
### Creating your own images
|
|
||||||
|
|
||||||
LXD being focused on running full Linux systems means that we expect most users to just use clean distribution images and not spin their own image.
|
|
||||||
|
|
||||||
However there are a few cases where having your own images is useful. Such as having pre-configured images of your production servers or building your own images for a distribution or architecture that we don’t build images for.
|
|
||||||
|
|
||||||
#### Turning a container into an image
|
|
||||||
|
|
||||||
The easiest way by far to build an image with LXD is to just turn a container into an image.
|
|
||||||
|
|
||||||
This can be done with:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc launch ubuntu:14.04 my-container
|
|
||||||
lxc exec my-container bash
|
|
||||||
<do whatever change you want>
|
|
||||||
lxc publish my-container --alias my-new-image
|
|
||||||
```
|
|
||||||
|
|
||||||
You can even turn a past container snapshot into a new image:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc publish my-container/some-snapshot --alias some-image
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Manually building an image
|
|
||||||
|
|
||||||
Building your own image is also pretty simple.
|
|
||||||
|
|
||||||
1. Generate a container filesystem. This entirely depends on the distribution you’re using. For Ubuntu and Debian, it would be by using debootstrap.
|
|
||||||
2. Configure anything that’s needed for the distribution to work properly in a container (if anything is needed).
|
|
||||||
3. Make a tarball of that container filesystem, optionally compress it.
|
|
||||||
4. Write a new metadata.yaml file based on the one described above.
|
|
||||||
5. Create another tarball containing that metadata.yaml file.
|
|
||||||
6. Import those two tarballs as a LXD image with:
|
|
||||||
```
|
|
||||||
lxc image import <metadata tarball> <rootfs tarball> --alias some-name
|
|
||||||
```
|
|
||||||
|
|
||||||
You will probably need to go through this a few times before everything works, tweaking things here and there, possibly adding some templates and properties.
|
|
||||||
|
|
||||||
### Publishing your images
|
|
||||||
|
|
||||||
All LXD daemons act as image servers. Unless told otherwise all images loaded in the image store are marked as private and so only trusted clients can retrieve those images, but should you want to make a public image server, all you have to do is tag a few images as public and make sure you LXD daemon is listening to the network.
|
|
||||||
|
|
||||||
#### Just running a public LXD server
|
|
||||||
|
|
||||||
The easiest way to share LXD images is to run a publicly visible LXD daemon.
|
|
||||||
|
|
||||||
You typically do that by running:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc config set core.https_address "[::]:8443"
|
|
||||||
```
|
|
||||||
|
|
||||||
Remote users can then add your server as a public image server with:
|
|
||||||
|
|
||||||
```
|
|
||||||
lxc remote add <some name> <IP or DNS> --public
|
|
||||||
```
|
|
||||||
|
|
||||||
They can then use it just as they would any of the default image servers. As the remote server was added with “–public”, no authentication is required and the client is restricted to images which have themselves been marked as public.
|
|
||||||
|
|
||||||
To change what images are public, just “lxc image edit” them and set the public flag to true.
|
|
||||||
|
|
||||||
#### Use a static web server
|
|
||||||
|
|
||||||
As mentioned above, “lxc image import” supports downloading from a static http server. The requirements are basically:
|
|
||||||
|
|
||||||
* The server must support HTTPs with a valid certificate, TLS1.2 and EC ciphers
|
|
||||||
* When hitting the URL provided to “lxc image import”, the server must return an answer including the LXD-Image-Hash and LXD-Image-URL HTTP headers
|
|
||||||
|
|
||||||
If you want to make this dynamic, you can have your server look for the LXD-Server-Architectures and LXD-Server-Version HTTP headers which LXD will provide when fetching the image. This allows you to return the right image for the server’s architecture.
|
|
||||||
|
|
||||||
#### Build a simplestreams server
|
|
||||||
|
|
||||||
The “ubuntu:” and “ubuntu-daily:” remotes aren’t using the LXD protocol (“images:” is), those are instead using a different protocol called simplestreams.
|
|
||||||
|
|
||||||
simplestreams is basically an image server description format, using JSON to describe a list of products and files related to those products.
|
|
||||||
|
|
||||||
It is used by a variety of tools like OpenStack, Juju, MAAS, … to find, download or mirror system images and LXD supports it as a native protocol for image retrieval.
|
|
||||||
|
|
||||||
While certainly not the easiest way to start providing LXD images, it may be worth considering if your images can also be used by some of those other tools.
|
|
||||||
|
|
||||||
More information can be found here.
|
|
||||||
|
|
||||||
### Conclusion
|
|
||||||
|
|
||||||
I hope this gave you a good idea of how LXD manages its images and how to build and distribute your own. The ability to have the exact same image easily available bit for bit on a bunch of globally distributed system is a big step up from the old LXC days and leads the way to more reproducible infrastructure.
|
|
||||||
|
|
||||||
### Extra information
|
|
||||||
|
|
||||||
The main LXD website is at: <https://linuxcontainers.org/lxd>
|
|
||||||
Development happens on Github at: <https://github.com/lxc/lxd>
|
|
||||||
Mailing-list support happens on: <https://lists.linuxcontainers.org>
|
|
||||||
IRC support happens in: #lxcontainers on irc.freenode.net
|
|
||||||
|
|
||||||
And if you don’t want or can’t install LXD on your own machine, you can always [try it online instead][3]!
|
|
||||||
|
|
||||||
|
|
||||||
--------------------------------------------------------------------------------
|
|
||||||
|
|
||||||
via: https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/
|
|
||||||
|
|
||||||
作者：[Stéphane Graber][a]
|
|
||||||
译者：[译者ID](https://github.com/译者ID)
|
|
||||||
校对：[校对者ID](https://github.com/校对者ID)
|
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 组织翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
|
||||||
|
|
||||||
[a]: https://www.stgraber.org/author/stgraber/
|
|
||||||
[0]: https://www.stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
|
|
||||||
[1]: https://github.com/lxc/lxd/blob/master/doc/image-handling.md
|
|
||||||
[2]: https://launchpad.net/simplestreams
|
|
||||||
[3]: https://linuxcontainers.org/lxd/try-it
|
|
||||||
|
|
||||||
原文：https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/
|
|
||||||
@ -379,12 +379,15 @@ LXD团队花费了几个月的时间来迭代我们使用的这些限制语言
|
|||||||
|
|
||||||
实时的应用限制和继承配置文件，使其成为一种非常强大的工具，可以在不影响正在运行的服务的情况下实时管理服务器上的负载。
|
实时的应用限制和继承配置文件，使其成为一种非常强大的工具，可以在不影响正在运行的服务的情况下实时管理服务器上的负载。
|
||||||
|
|
||||||
### 额外的信息
|
### 额外信息
|
||||||
|
|
||||||
LXD主站： <https://linuxcontainers.org/lxd>
|
LXD 的主站在: <https://linuxcontainers.org/lxd>
|
||||||
Github上的页面： <https://github.com/lxc/lxd>
|
|
||||||
邮件列表： <https://lists.linuxcontainers.org>
|
LXD 的 GitHub 仓库: <https://github.com/lxc/lxd>
|
||||||
IRC：#lxcontainers on irc.freenode.net
|
|
||||||
|
LXD 的邮件列表: <https://lists.linuxcontainers.org>
|
||||||
|
|
||||||
|
LXD 的 IRC 频道: #lxcontainers on irc.freenode.net
|
||||||
|
|
||||||
如果你不想在你的机器上安装LXD，你可以[在线尝试下][3]
|
如果你不想在你的机器上安装LXD，你可以[在线尝试下][3]
|
||||||
|
|
||||||
|
|||||||
473
translated/tech/LXD/Part 5 - LXD 2.0--Image management.md
Normal file
473
translated/tech/LXD/Part 5 - LXD 2.0--Image management.md
Normal file
@ -0,0 +1,473 @@
|
|||||||
|
LXD 2.0 系列（五）：镜像管理
|
||||||
|
======================================
|
||||||
|
|
||||||
|
这是 [LXD 2.0 系列介绍文章][0]的第五篇。
|
||||||
|
|
||||||
|
因为lxd容器管理有很多命令，因此这篇文章会很长。 如果你想要快速地浏览这些相同的命令，你可以[尝试下我们的在线演示][1]！
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 容器镜像
|
||||||
|
|
||||||
|
如果你以前使用过LXC，你可能还记得那些LXC“模板”，基本上都是导出一个容器文件系统以及一点配置的shell脚本。
|
||||||
|
|
||||||
|
大多数模板通过在本机上根据发行版自举来生成文件系统。这可能需要相当长的时间，并且无法在所有的发行版上可用，另外可能需要大量的网络带宽。
|
||||||
|
|
||||||
|
回到LXC 1.0，我写了一个“下载”模板，它允许用户下载预先打包的容器镜像，在中央服务器上的模板脚本生成，接着高度压缩、签名并通过https分发。我们很多用户从旧版生成容器切换到使用这种新的，更快更可靠的创建容器的方法。
|
||||||
|
|
||||||
|
使用LXD，我们通过全面的基于镜像的工作流程向前迈进了一步。所有容器都是从镜像创建的，我们在LXD中具有高级镜像缓存和预加载支持，以使镜像存储保持最新。
|
||||||
|
|
||||||
|
### 与LXD镜像交互
|
||||||
|
|
||||||
|
在更深入了解镜像格式之前，让我们快速了解下LXD可以让你做些什么。
|
||||||
|
|
||||||
|
#### 透明地导入镜像
|
||||||
|
|
||||||
|
所有的容器都是有镜像创建的。镜像可以来自一台远程服务器并使用它的完整hash、短hash或者别名拉取下来，但是最终每个LXD容器都是创建自一个本地镜像。
|
||||||
|
|
||||||
|
这有个例子：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc launch ubuntu:14.04 c1
|
||||||
|
lxc launch ubuntu:75182b1241be475a64e68a518ce853e800e9b50397d2f152816c24f038c94d6e c2
|
||||||
|
lxc launch ubuntu:75182b1241be c3
|
||||||
|
```
|
||||||
|
|
||||||
|
所有这些引用相同的远程镜像（在写这篇文章时）在第一次运行其中之一时，远程镜像将作为缓存镜像导入本地LXD镜像存储，接着从中创建容器。
|
||||||
|
|
||||||
|
下一次运行其中一个命令时，LXD将只检查镜像是否仍然是最新的（当不是由指纹引用时），如果是，它将创建容器而不下载任何东西。
|
||||||
|
|
||||||
|
现在镜像被缓存在本地镜像存储中，你也可以从那里启动它，甚至不检查它是否是最新的：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc launch 75182b1241be c4
|
||||||
|
```
|
||||||
|
|
||||||
|
最后，如果你有个名为“myimage”的本地镜像，你可以：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc launch my-image c5
|
||||||
|
```
|
||||||
|
|
||||||
|
如果你想要改变一些自动缓存或者过期行为，在本系列之前的文章中有一些命令。
|
||||||
|
|
||||||
|
#### 手动导入镜像
|
||||||
|
|
||||||
|
##### 从镜像服务器中复制
|
||||||
|
|
||||||
|
如果你想复制远程某个镜像到你本地镜像存储但不立即从它创建一个容器，你可以使用“lxc image copy”命令。它可以让你调整一些镜像标志，比如：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image copy ubuntu:14.04 local:
|
||||||
|
```
|
||||||
|
|
||||||
|
这只是简单地复制一个远程镜像到本地存储。
|
||||||
|
|
||||||
|
如果您想要通过比其指纹更容易的方式来记住你引用的镜像副本，则可以在复制时添加别名：
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image copy ubuntu:12.04 local: --alias old-ubuntu
|
||||||
|
lxc launch old-ubuntu c6
|
||||||
|
```
|
||||||
|
|
||||||
|
如果你想要使用源服务器上设置的别名，你可以要求LXD复制下来：
|
||||||
|
|
||||||
|
lxc image copy ubuntu:15.10 local: --copy-aliases
|
||||||
|
lxc launch 15.10 c7
|
||||||
|
|
||||||
|
上面的副本都是一次性拷贝，也就是复制远程镜像的当前版本到本地镜像存储中。如果你想要LXD保持镜像最新，就像它缓存中存储的那样，你需要使用`–auto-update`标志：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image copy images:gentoo/current/amd64 local: --alias gentoo --auto-update
|
||||||
|
```
|
||||||
|
|
||||||
|
##### 导入tarball
|
||||||
|
|
||||||
|
如果某人给你提供了一个单独的tarball，你可以用下面的命令导入：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image import <tarball>
|
||||||
|
```
|
||||||
|
|
||||||
|
如果你想在导入时设置一个别名，你可以这么做：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image import <tarball> --alias random-image
|
||||||
|
```
|
||||||
|
|
||||||
|
现在如果你被给了有两个tarball，识别哪个含有LXD的元数据。通常可以通过tarball名称，如果不行就选择最小的那个，元数据tarball包是很小的。 然后将它们一起导入：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image import <metadata tarball> <rootfs tarball>
|
||||||
|
```
|
||||||
|
|
||||||
|
##### 从URL中导入
|
||||||
|
|
||||||
|
“lxc image import”也可以与指定的URL一起使用。如果你的一台https网络服务器的某个路径中有LXD-Image-URL和LXD-Image-Hash的标头设置，那么LXD就会把这个镜像拉到镜像存储中。
|
||||||
|
|
||||||
|
可以参照例子这么做：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image import https://dl.stgraber.org/lxd --alias busybox-amd64
|
||||||
|
```
|
||||||
|
|
||||||
|
当拉取镜像时，LXD还会设置一些标头，远程服务器可以检查它们以返回适当的镜像。 它们是LXD-Server-Architectures和LXD-Server-Version。
|
||||||
|
|
||||||
|
这意味着它可以是一个穷人的镜像服务器。 它可以使任何静态Web服务器提供一个用户友好的方式导入你的镜像。
|
||||||
|
|
||||||
|
|
||||||
|
#### 管理本地镜像存储
|
||||||
|
|
||||||
|
现在我们本地已经有一些镜像了，让我们瞧瞧可以做些什么。我们已经涵盖了最主要的部分，从它们来创建容器，但是你还可以在本地镜像存储上做更多。
|
||||||
|
|
||||||
|
##### 列出镜像
|
||||||
|
|
||||||
|
要列出所有的镜像，运行“lxc image list”：
|
||||||
|
|
||||||
|
```
|
||||||
|
stgraber@dakara:~$ lxc image list
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| alpine-32 | 6d9c131efab3 | yes | Alpine edge (i386) (20160329_23:52) | i686 | 2.50MB | Mar 30, 2016 at 4:36am (UTC) |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| busybox-amd64 | 74186c79ca2f | no | Busybox x86_64 | x86_64 | 0.79MB | Mar 30, 2016 at 4:33am (UTC) |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| gentoo | 1a134c5951e0 | no | Gentoo current (amd64) (20160329_14:12) | x86_64 | 232.50MB | Mar 30, 2016 at 4:34am (UTC) |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| my-image | c9b6e738fae7 | no | Scientific Linux 6 x86_64 (default) (20160215_02:36) | x86_64 | 625.34MB | Mar 2, 2016 at 4:56am (UTC) |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| old-ubuntu | 4d558b08f22f | no | ubuntu 12.04 LTS amd64 (release) (20160315) | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| w (11 more) | d3703a994910 | no | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| | 75182b1241be | no | ubuntu 14.04 LTS amd64 (release) (20160314) | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |
|
||||||
|
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
|
你可以通过别名或者指纹来过滤：
|
||||||
|
|
||||||
|
```
|
||||||
|
stgraber@dakara:~$ lxc image list amd64
|
||||||
|
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
||||||
|
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
|
||||||
|
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
||||||
|
| busybox-amd64 | 74186c79ca2f | no | Busybox x86_64 | x86_64 | 0.79MB | Mar 30, 2016 at 4:33am (UTC) |
|
||||||
|
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
||||||
|
| w (11 more) | d3703a994910 | no | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|
||||||
|
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
|
或者指定一个镜像属性中的键值对来过滤：
|
||||||
|
|
||||||
|
```
|
||||||
|
stgraber@dakara:~$ lxc image list os=ubuntu
|
||||||
|
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
|
||||||
|
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| old-ubuntu | 4d558b08f22f | no | ubuntu 12.04 LTS amd64 (release) (20160315) | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
|
||||||
|
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| w (11 more) | d3703a994910 | no | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
|
||||||
|
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
||||||
|
| | 75182b1241be | no | ubuntu 14.04 LTS amd64 (release) (20160314) | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |
|
||||||
|
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
|
要了解所有镜像的信息，你可以使用“lxc image info”：
|
||||||
|
|
||||||
|
```
|
||||||
|
stgraber@castiana:~$ lxc image info ubuntu
|
||||||
|
Fingerprint: e8a33ec326ae7dd02331bd72f5d22181ba25401480b8e733c247da5950a7d084
|
||||||
|
Size: 139.43MB
|
||||||
|
Architecture: i686
|
||||||
|
Public: no
|
||||||
|
Timestamps:
|
||||||
|
Created: 2016/03/15 00:00 UTC
|
||||||
|
Uploaded: 2016/03/16 05:50 UTC
|
||||||
|
Expires: 2017/04/26 00:00 UTC
|
||||||
|
Properties:
|
||||||
|
version: 12.04
|
||||||
|
aliases: 12.04,p,precise
|
||||||
|
architecture: i386
|
||||||
|
description: ubuntu 12.04 LTS i386 (release) (20160315)
|
||||||
|
label: release
|
||||||
|
os: ubuntu
|
||||||
|
release: precise
|
||||||
|
serial: 20160315
|
||||||
|
Aliases:
|
||||||
|
- ubuntu
|
||||||
|
Auto update: enabled
|
||||||
|
Source:
|
||||||
|
Server: https://cloud-images.ubuntu.com/releases
|
||||||
|
Protocol: simplestreams
|
||||||
|
Alias: precise/i386
|
||||||
|
```
|
||||||
|
|
||||||
|
##### 编辑镜像
|
||||||
|
|
||||||
|
一个编辑镜像的属性和标志的简单方法是使用：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image edit <alias or fingerprint>
|
||||||
|
```
|
||||||
|
|
||||||
|
这会打开默认文本编辑器，内容像这样：
|
||||||
|
|
||||||
|
```
|
||||||
|
autoupdate: true
|
||||||
|
properties:
|
||||||
|
aliases: 14.04,default,lts,t,trusty
|
||||||
|
architecture: amd64
|
||||||
|
description: ubuntu 14.04 LTS amd64 (release) (20160314)
|
||||||
|
label: release
|
||||||
|
os: ubuntu
|
||||||
|
release: trusty
|
||||||
|
serial: "20160314"
|
||||||
|
version: "14.04"
|
||||||
|
public: false
|
||||||
|
```
|
||||||
|
|
||||||
|
你可以修改任何属性，打开或者关闭自动更新，后者标记一个镜像是公共的（以后还有更多）
|
||||||
|
|
||||||
|
##### 删除镜像
|
||||||
|
|
||||||
|
删除镜像只需要运行：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc image delete <alias or fingerprint>
|
||||||
|
```
|
||||||
|
|
||||||
|
注意你不必移除缓存对象，它们会在过期后被LXD自动移除（默认上，在最后一次使用的10天后）。
|
||||||
|
|
||||||
|
##### 导出镜像
|
||||||
|
|
||||||
|
如果你想得到目前镜像的tarball，你可以使用“lxc image export”，像这样：
|
||||||
|
|
||||||
|
```
|
||||||
|
stgraber@dakara:~$ lxc image export old-ubuntu .
|
||||||
|
Output is in .
|
||||||
|
stgraber@dakara:~$ ls -lh *.tar.xz
|
||||||
|
-rw------- 1 stgraber domain admins 656 Mar 30 00:55 meta-ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz
|
||||||
|
-rw------- 1 stgraber domain admins 156M Mar 30 00:55 ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 镜像格式
|
||||||
|
|
||||||
|
LXD现在支持两种镜像布局，unified或者split。这两者都是有效的LXD格式，虽然后者在与其他容器或虚拟机一起运行时更容易重新使用文件系统。
|
||||||
|
|
||||||
|
LXD专注于系统容器，不支持任何应用程序容器的“标准”镜像格式，我们也不打算这么做。
|
||||||
|
|
||||||
|
我们的镜像很简单，它们是由容器文件系统，以及包含了镜像制作时间、到期时间、什么架构，以及可选的一堆文件模板的元数据文件组成。
|
||||||
|
|
||||||
|
有关[镜像格式][1]的最新详细信息，请参阅此文档。
|
||||||
|
|
||||||
|
##### unified镜像 (一个tarball)
|
||||||
|
|
||||||
|
unified镜像格式是LXD在生成镜像时使用的格式。它们是一个单独的大型tarball，包含“rootfs”目录的容器文件系统，在tarball根目录下有metadata.yaml文件，任何模板都进入“templates”目录。
|
||||||
|
|
||||||
|
tarball可以用任何方式压缩（或者不压缩）。镜像散列是压缩后的tarball的sha256。
|
||||||
|
|
||||||
|
|
||||||
|
##### Split镜像 (两个tarball)
|
||||||
|
|
||||||
|
这种格式最常用于滚动更新镜像以及某人已经有了一个压缩文件系统tarball。
|
||||||
|
|
||||||
|
它们由两个不同的tarball组成，第一个只包含LXD使用的元数据，因此metadata.yaml文件在根目录，任何模板都在“templates”目录。
|
||||||
|
|
||||||
|
第二个tarball只包含直接位于其根目录下的容器文件系统。大多数发行版已经有这样的tarball，因为它们常用于引导新机器。 此镜像格式允许不修改重新使用。
|
||||||
|
|
||||||
|
两个tarball都可以压缩（或者不压缩），它们可以使用不同的压缩算法。 镜像散列是元数据和rootfs tarball结合的sha256。
|
||||||
|
|
||||||
|
##### 镜像元数据
|
||||||
|
|
||||||
|
典型的metadata.yaml文件看起来像这样：
|
||||||
|
|
||||||
|
```
|
||||||
|
architecture: "i686"
|
||||||
|
creation_date: 1458040200
|
||||||
|
properties:
|
||||||
|
architecture: "i686"
|
||||||
|
description: "Ubuntu 12.04 LTS server (20160315)"
|
||||||
|
os: "ubuntu"
|
||||||
|
release: "precise"
|
||||||
|
templates:
|
||||||
|
/var/lib/cloud/seed/nocloud-net/meta-data:
|
||||||
|
when:
|
||||||
|
- start
|
||||||
|
template: cloud-init-meta.tpl
|
||||||
|
/var/lib/cloud/seed/nocloud-net/user-data:
|
||||||
|
when:
|
||||||
|
- start
|
||||||
|
template: cloud-init-user.tpl
|
||||||
|
properties:
|
||||||
|
default: |
|
||||||
|
#cloud-config
|
||||||
|
{}
|
||||||
|
/var/lib/cloud/seed/nocloud-net/vendor-data:
|
||||||
|
when:
|
||||||
|
- start
|
||||||
|
template: cloud-init-vendor.tpl
|
||||||
|
properties:
|
||||||
|
default: |
|
||||||
|
#cloud-config
|
||||||
|
{}
|
||||||
|
/etc/init/console.override:
|
||||||
|
when:
|
||||||
|
- create
|
||||||
|
template: upstart-override.tpl
|
||||||
|
/etc/init/tty1.override:
|
||||||
|
when:
|
||||||
|
- create
|
||||||
|
template: upstart-override.tpl
|
||||||
|
/etc/init/tty2.override:
|
||||||
|
when:
|
||||||
|
- create
|
||||||
|
template: upstart-override.tpl
|
||||||
|
/etc/init/tty3.override:
|
||||||
|
when:
|
||||||
|
- create
|
||||||
|
template: upstart-override.tpl
|
||||||
|
/etc/init/tty4.override:
|
||||||
|
when:
|
||||||
|
- create
|
||||||
|
template: upstart-override.tpl
|
||||||
|
```
|
||||||
|
|
||||||
|
##### 属性
|
||||||
|
|
||||||
|
两个唯一的必填字段是“creation date”（UNIX EPOCH）和“architecture”。 其他都可以保持未设置，镜像就可以正常地导入。
|
||||||
|
|
||||||
|
额外的属性主要是帮助用户弄清楚镜像是什么。 例如“description”属性是在“lxc image list”中可见的。 用户可以使用其他属性的键/值对来搜索特定镜像。
|
||||||
|
|
||||||
|
相反，这些属性用户可以通过“lxc image edit”来编辑，“creation date”和“architecture”字段是不可变的。
|
||||||
|
|
||||||
|
##### 模板
|
||||||
|
|
||||||
|
模板机制允许在容器生命周期中的某一点生成或重新生成容器中的一些文件。
|
||||||
|
|
||||||
|
我们使用pongo2模板引擎来做这些，我们将所有我们知道的容器导出到模板。 这样，你可以使用用户定义的容器属性或常规LXD属性的自定义镜像来更改某些特定文件的内容。
|
||||||
|
|
||||||
|
正如你在上面的例子中看到的，我们使用在Ubuntu中的模板找出cloud-init并关闭一些init脚本。
|
||||||
|
|
||||||
|
### 创建你的镜像
|
||||||
|
|
||||||
|
LXD专注于运行完整的Linux系统，这意味着我们期望大多数用户只使用干净的发行版镜像，而不是只用自己的镜像。
|
||||||
|
|
||||||
|
但是有一些情况下，你有自己的镜像是有用的。 例如生产服务器上的预配置镜像，或者构建那些我们没有构建的发行版或者架构的镜像。
|
||||||
|
|
||||||
|
#### 将容器变成镜像
|
||||||
|
|
||||||
|
目前使用LXD构造镜像最简单的方法是将容器变成镜像。
|
||||||
|
|
||||||
|
可以这么做
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc launch ubuntu:14.04 my-container
|
||||||
|
lxc exec my-container bash
|
||||||
|
<do whatever change you want>
|
||||||
|
lxc publish my-container --alias my-new-image
|
||||||
|
```
|
||||||
|
|
||||||
|
你甚至可以将一个容器过去的snapshot变成镜像：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc publish my-container/some-snapshot --alias some-image
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 手动构建镜像
|
||||||
|
|
||||||
|
构建你自己的镜像也很简单。
|
||||||
|
|
||||||
|
1.生成容器文件系统。 这完全取决于你使用的发行版。 对于Ubuntu和Debian，它将用于启动。
|
||||||
|
2.配置容器中正常工作所需的任何东西（如果需要任何东西）。
|
||||||
|
3.制作该容器文件系统的tarball，可选择压缩它。
|
||||||
|
4.根据上面描述的内容写一个新的metadata.yaml文件。
|
||||||
|
5.创建另一个包含metadata.yaml文件的压缩包。
|
||||||
|
6.用下面的命令导入这两个tarball作为LXD镜像：
|
||||||
|
```
|
||||||
|
lxc image import <metadata tarball> <rootfs tarball> --alias some-name
|
||||||
|
```
|
||||||
|
|
||||||
|
正常工作前你可能需要经历几次这样的工作，调整这里或那里，可能会添加一些模板和属性。
|
||||||
|
|
||||||
|
### 发布你的镜像
|
||||||
|
|
||||||
|
所有LXD守护程序都充当镜像服务器。除非另有说明，否则加载到镜像存储中的所有镜像都会被标记为私有，因此只有受信任的客户端可以检索这些镜像，但是如果要创建公共镜像服务器，你需要做的是将一些镜像标记为公开，并确保你的LXD守护进程监听网络。
|
||||||
|
|
||||||
|
#### 只运行LXD公共服务器
|
||||||
|
|
||||||
|
最简单的共享镜像的方式是运行一个公共的LXD守护进程。
|
||||||
|
|
||||||
|
你只要运行：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc config set core.https_address "[::]:8443"
|
||||||
|
```
|
||||||
|
|
||||||
|
远程用户就可以添加你的服务器作为公共服务器：
|
||||||
|
|
||||||
|
```
|
||||||
|
lxc remote add <some name> <IP or DNS> --public
|
||||||
|
```
|
||||||
|
|
||||||
|
他们就可以像任何默认的镜像服务器一样使用它们。 由于远程服务器添加了“-public”，因此不需要身份验证，并且客户端仅限于使用已标记为public的镜像。
|
||||||
|
|
||||||
|
要将镜像设置成公共的，只需“lxc image edit”它们，并将public标志设置为true。
|
||||||
|
|
||||||
|
#### 使用一台静态web服务器
|
||||||
|
|
||||||
|
如上所述，“lxc image import”支持从静态http服务器下载。 基本要求是：
|
||||||
|
|
||||||
|
*服务器必须支持具有有效证书的HTTPS，TLS1.2和EC密钥
|
||||||
|
*当点击“lxc image import”提供的URL时，服务器必须返回一个包含LXD-Image-Hash和LXD-Image-URL的HTTP标头。
|
||||||
|
|
||||||
|
如果你想使它动态化，你可以让你的服务器查找LXD在请求镜像中发送的LXD-Server-Architectures和LXD-Server-Version的HTTP头。 这可以让你返回架构正确的镜像。
|
||||||
|
|
||||||
|
#### 构建一个简单流服务器
|
||||||
|
|
||||||
|
“ubuntu:”和“ubuntu-daily:”在远端不使用LXD协议（“images:”是的），而是使用不同的协议称为简单流。
|
||||||
|
|
||||||
|
简单流基本上是一个镜像服务器的描述格式，使用JSON来描述产品以及相关产品的文件列表。
|
||||||
|
|
||||||
|
它被各种工具，如OpenStack，Juju，MAAS等用来查找，下载或者做镜像系统，LXD将它作为原生协议支持用于镜像检索。
|
||||||
|
|
||||||
|
虽然的确不是提供LXD镜像的最简单的方法，但是如果你的镜像也被其他一些工具使用，那这也许值得考虑一下。
|
||||||
|
|
||||||
|
更多信息可以在这里找到。
|
||||||
|
|
||||||
|
### 总结
|
||||||
|
|
||||||
|
我希望关于如何使用LXD管理镜像以及构建和发布镜像这点给你提供了一个好点子。对于以前的LXC而言可以在一组全球分布式系统上得到完全相同的镜像是一个很大的进步，并且让将来的道路更加可复制。
|
||||||
|
|
||||||
|
|
||||||
|
### 额外信息
|
||||||
|
|
||||||
|
LXD 的主站在: <https://linuxcontainers.org/lxd>
|
||||||
|
|
||||||
|
LXD 的 GitHub 仓库: <https://github.com/lxc/lxd>
|
||||||
|
|
||||||
|
LXD 的邮件列表: <https://lists.linuxcontainers.org>
|
||||||
|
|
||||||
|
LXD 的 IRC 频道: #lxcontainers on irc.freenode.net
|
||||||
|
|
||||||
|
如果你不想或者不能在你的机器上安装 LXD ，你可以在 web 上[试试在线版的 LXD][3] 。
|
||||||
|
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/
|
||||||
|
|
||||||
|
作者：[Stéphane Graber][a]
|
||||||
|
译者：[geekpi](https://github.com/geekpi)
|
||||||
|
校对：[校对者ID](https://github.com/校对者ID)
|
||||||
|
|
||||||
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 组织翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||||
|
|
||||||
|
[a]: https://www.stgraber.org/author/stgraber/
|
||||||
|
[0]: https://www.stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
|
||||||
|
[1]: https://github.com/lxc/lxd/blob/master/doc/image-handling.md
|
||||||
|
[2]: https://launchpad.net/simplestreams
|
||||||
|
[3]: https://linuxcontainers.org/lxd/try-it
|
||||||
|
|
||||||
|
原文：https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/
|
||||||
Loading…
Reference in New Issue
Block a user