From 1e083a61610621011c2b6d0d9e810f882f8b2771 Mon Sep 17 00:00:00 2001 From: darksun Date: Thu, 22 Feb 2018 15:42:12 +0800 Subject: [PATCH] remove blog.simos.info --- ... addresses from your LAN using a bridge.md | 173 -------------- .../20180129 How to use LXD instance types.md | 225 ------------------ ...How to use lxc remote with the LXD snap.md | 106 --------- 3 files changed, 504 deletions(-) delete mode 100644 sources/tech/20180129 How to make your LXD containers get IP addresses from your LAN using a bridge.md delete mode 100644 sources/tech/20180129 How to use LXD instance types.md delete mode 100644 sources/tech/20180201 How to use lxc remote with the LXD snap.md diff --git a/sources/tech/20180129 How to make your LXD containers get IP addresses from your LAN using a bridge.md b/sources/tech/20180129 How to make your LXD containers get IP addresses from your LAN using a bridge.md deleted file mode 100644 index 6f26f182b8..0000000000 --- a/sources/tech/20180129 How to make your LXD containers get IP addresses from your LAN using a bridge.md +++ /dev/null @@ -1,173 +0,0 @@ -How to make your LXD containers get IP addresses from your LAN using a bridge -====== -**Background** : LXD is a hypervisor that manages machine containers on Linux distributions. You install LXD on your Linux distribution and then you can launch machine containers into your distribution running all sort of (other) Linux distributions. - -In the previous post, we saw how to get our LXD container to receive an IP address from the local network (instead of getting the default private IP address), using **macvlan**. - -In this post, we are going to see how to use a **bridge** to make our containers get an IP address from the local network. Specifically, we are going to see how to do this using NetworkManager. If you have several public IP addresses, you can use this method (or the other with the **macvlan** ) in order to expose your LXD containers directly to the Internet. - -### Creating the bridge with NetworkManager - -See this post [How to configure a Linux bridge with Network Manager on Ubuntu][1] on how to create the bridge with NetworkManager. It explains that you - - 1. Use **NetworkManager** to **Add a New Connection** , a **Bridge**. - 2. When configuring the **Bridge** , you specify the real network connection (the device, like **eth0** or **enp3s12** ) that will be **the slave of the bridge**. You can verify the device of the network connection if you run **ip route list 0.0.0.0/0**. - 3. Then, you can remove the old network connection and just keep the slave. The slave device ( **bridge0** ) will now be the device that gets you your LAN IP address. - - - -At this point you would have again network connectivity. Here is the new device, **bridge0**. -``` -$ ifconfig bridge0 -bridge0 Link encap:Ethernet HWaddr 00:e0:4b:e0:a8:c2 - inet addr:192.168.1.64 Bcast:192.168.1.255 Mask:255.255.255.0 - inet6 addr: fe80::d3ca:7a11:f34:fc76/64 Scope:Link - UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 - RX packets:9143 errors:0 dropped:0 overruns:0 frame:0 - TX packets:7711 errors:0 dropped:0 overruns:0 carrier:0 - collisions:0 txqueuelen:1000 - RX bytes:7982653 (7.9 MB) TX bytes:1056263 (1.0 MB) -``` - -### Creating a new profile in LXD for bridge networking - -In LXD, there is a default profile and then you can create additional profile that either are independent from the default (like in the **macvlan** post), or can be chained with the default profile. Now we see the latter. - -First, create a new and empty LXD profile, called **bridgeprofile**. -``` -$ lxc create profile bridgeprofile -``` - -Here is the fragment to add to the new profile. The **eth0** is the interface name in the container, so for the Ubuntu containers it does not change. Then, **bridge0** is the interface that was created by NetworkManager. If you created that bridge by some other way, add here the appropriate interface name. The **EOF** at the end is just a marker when we copy and past to the profile. -``` -description: Bridged networking LXD profile -devices: - eth0: - name: eth0 - nictype: bridged - parent: bridge0 - type: nic -**EOF** -``` - -Paste the fragment to the new profile. -``` -$ cat <:] [:][] [--ephemeral|-e] [--profile|-p ...] [--config|-c ...] [--type|-t ] - -Create and start containers from images. - -Not specifying -p will result in the default profile. -Specifying "-p" with no argument will result in no profile. - -Examples: - lxc launch ubuntu:16.04 u1 - -Options: - -c, --config (= map[]) Config key/value to apply to the new container - --debug (= false) Enable debug mode - -e, --ephemeral (= false) Ephemeral container - --force-local (= false) Force using the local unix socket - --no-alias (= false) Ignore aliases when determining what command to run - -p, --profile (= []) Profile to apply to the new container -**-t (= "") Instance type** - --verbose (= false) Enable verbose mode -``` - -What do we put for Instance type? Here is the documentation, - - - -Simply put, an instance type is just a mnemonic shortcut for specific pair of CPU cores and RAM memory settings. For CPU you specify the number of cores and for RAM memory the amount in GB (assuming your own computer has enough cores and RAM so that LXD can allocate them to the newly created container). - -You would need an instance type if you want to create a machine container that resembles in the specs as close as possible what you will be installing later on, on AWS (Amazon), Azure (Microsoft) or GCE (Google). - -The instance type can have any of the following forms, - - * `` for example: **t2.micro** (LXD figures out that this refers to AWS t2.micro, therefore 1 core, 1GB RAM). - * `:` for example, **aws:t2.micro** (LXD quickly looks into the AWS types, therefore 1core, 1GB RAM). - * `c-m` for example, **c1-m1** (LXD explicitly allocates one core, and 1GB RAM). - - - -Where do these mnemonics like **t2.micro** come from? The documentation says from - -[![][1]][2] - -There are three sets of instance types, **aws** , **azure** and **gce**. Their names are listed in [the LXD instance type index file ][3]**.yaml,** -``` -aws: "aws.yaml" -gce: "gce.yaml" -azure: "azure.yaml" - -``` - -Over there, there are YAML configuration files for each of AWS, Azure and GCE, and in them there are settings for CPU cores and RAM memory. - -The actual URLs that the LXD client will be using, are - - - -Sample for AWS: -``` -t2.large: - cpu: 2.0 - mem: 8.0 -t2.medium: - cpu: 2.0 - mem: 4.0 -t2.micro: - cpu: 1.0 - mem: 1.0 -t2.nano: - cpu: 1.0 - mem: 0.5 -t2.small: - cpu: 1.0 - mem: 2.0 -``` - - - -Sample for Azure: -``` -ExtraSmall: - cpu: 1.0 - mem: 0.768 -Large: - cpu: 4.0 - mem: 7.0 -Medium: - cpu: 2.0 - mem: 3.5 -Small: - cpu: 1.0 - mem: 1.75 -Standard_A1_v2: - cpu: 1.0 - mem: 2.0 -``` - - - -Sample for GCE: -``` -f1-micro: - cpu: 0.2 - mem: 0.6 -g1-small: - cpu: 0.5 - mem: 1.7 -n1-highcpu-16: - cpu: 16.0 - mem: 14.4 -n1-highcpu-2: - cpu: 2.0 - mem: 1.8 -n1-highcpu-32: - cpu: 32.0 - mem: 28.8 -``` - -Let's see an example. Here, all of the following are all equivalent! Just run one of them to get a 1 CPU core/1GB RAM container. -``` -$ lxc launch ubuntu:x -t t2.micro aws-t2-micro - -$ lxc launch ubuntu:x -t aws:t2.micro aws-t2-micro - -$ lxc launch ubuntu:x -t c1-m1 aws-t2-micro -``` - -Let's verify that the constraints have been actually set for the container. -``` -$ lxc config get aws-t2-micro limits.cpu -1 - -$ lxc config get aws-t2-micro limits.cpu.allowance - - -$ lxc config get aws-t2-micro limits.memory -1024MB - -$ lxc config get aws-t2-micro limits.memory.enforce - - -``` - -There are generic limits for 1 CPU core and 1024MB/1GB RAM. For more, see [LXD resource control][4]. - -If you already have a running container and you wanted to set limits live (no need to restart it), here is how you would do that. -``` -$ lxc launch ubuntu:x mycontainer -Creating mycontainer -Starting mycontainer - -$ lxc config set mycontainer limits.cpu 1 -$ lxc config set mycontainer limits.memory 1GB -``` - -Let's see the config with the limits, -``` -$ lxc config show mycontainer -architecture: x86_64 -config: - image.architecture: amd64 - image.description: ubuntu 16.04 LTS amd64 (release) (20180126) - image.label: release - image.os: ubuntu - image.release: xenial - image.serial: "20180126" - image.version: "16.04" - limits.cpu: "1" - limits.memory: 1GB -... -``` - -### Troubleshooting - -#### I tried to the the memory limit but I get an error! - -I got this error, -``` -$ lxc config set mycontainer limits.memory 1 -error: Failed to set cgroup memory.limit_in_bytes="1": setting cgroup item for the container failed -Exit 1 -``` - -When you set the memory limit ( **limits.memory** ), you need to append a specifier like **GB** (as in 1GB). Because the number there is in bytes if no specifier is present, and one byte of memory is not going to work. - -#### I cannot set the limits in lxc launch -config! - -How do I use **lxc launch -config ConfigurationGoesHere**? - -Here is the documentation: -``` -$ lxc launch --help -Usage: lxc launch [ :] ... [--config|-c ...] -``` - -Here it is, -``` -$ lxc launch ubuntu:x --config limits.cpu=1 --config limits.memory=1GB mycontainer -Creating mycontainer -Starting mycontainer -``` - -That is, use multiple **- config** parameters. - - --------------------------------------------------------------------------------- - -via: https://blog.simos.info/how-to-use-lxd-instance-types/ - -作者：[Simos Xenitellis][a] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://blog.simos.info/author/simos/ -[1]:https://i1.wp.com/blog.simos.info/wp-content/uploads/2018/01/lxd-instance-types.png?resize=750%2C277&ssl=1 -[2]:https://i1.wp.com/blog.simos.info/wp-content/uploads/2018/01/lxd-instance-types.png?ssl=1 -[3]:https://uk.images.linuxcontainers.org/meta/instance-types/.yaml -[4]:https://stgraber.org/2016/03/26/lxd-2-0-resource-control-412/ diff --git a/sources/tech/20180201 How to use lxc remote with the LXD snap.md b/sources/tech/20180201 How to use lxc remote with the LXD snap.md deleted file mode 100644 index ccc7b40d02..0000000000 --- a/sources/tech/20180201 How to use lxc remote with the LXD snap.md +++ /dev/null @@ -1,106 +0,0 @@ -How to use lxc remote with the LXD snap -====== -**Background** : LXD is a hypervisor that manages machine containers on Linux distributions. You install LXD on your Linux distribution and then you can launch machine containers into your distribution running all sort of (other) Linux distributions. - -You have installed the LXD snap and you are happy using it. However, you are developing LXD and you would like to use your freshly compiled LXD client (executable: **lxc** ) on the LXD snap. - -Let’s run our compile lxc executable. -``` -$ ./lxc list -LXD socket not found; is LXD installed and running? -Exit 1 - -``` - -By default it cannot access the LXD server from the snap. We need to [set up a remote LXD host][1] and then configure the client to be able to connect to that remote LXD server. - -### Configuring the remote LXD server (snap) - -We run the following on the LXD snap, -``` -$ which lxd -/snap/bin/lxd - -$ sudo lxd init -Do you want to configure a new storage pool (yes/no) [default=yes]? no -Would you like LXD to be available over the network (yes/no) [default=no]? yes -Address to bind LXD to (not including port) [default=all]: press_enter_to_accept_default -Port to bind LXD to [default=8443]: press_enter_to_accept_default -Trust password for new clients: type_a_password -Again: type_the_same_password -Do you want to configure the LXD bridge (yes/no) [default=yes]? no -LXD has been successfully configured. - -$ - -``` - -Now the snap LXD server is configured to accept remote connections, and the clients much be configured with the correct trust password. - -### Configuring the client (compiled lxc) - -Let’s configure now the compiled lxc client. - -First, here is how the unconfigured compiled lxc client would react, -``` -$ ./lxc list -LXD socket not found; is LXD installed and running? -Exit 1 - -``` - -Now we add the remote, given the name **lxd.snap** , which binds on localhost (127.0.0.1). It asks to verify the certificate fingerprint. I am not aware how to view the fingerprint from inside the snap. We type the one-time password that we set earlier and we are good to go. -``` -$ lxc remote add lxd.snap 127.0.0.1 -Certificate fingerprint: 2c5829064cf795e29388b0d6310369fcf693257650b5c90c922a2d10f542831e -ok (y/n)? y -Admin password for lxd.snap: type_that_password -Client certificate stored at server: lxd.snap - -$ lxc remote list -+-----------------|------------------------------------------|---------------|-----------|--------|--------+ -| NAME | URL | PROTOCOL | AUTH TYPE | PUBLIC | STATIC | -+-----------------|------------------------------------------|---------------|-----------|--------|--------+ -| images | https://images.linuxcontainers.org | simplestreams | | YES | NO | -+-----------------|------------------------------------------|---------------|-----------|--------|--------+ -| local (default) | unix:// | lxd | tls | NO | YES | -+-----------------|------------------------------------------|---------------|-----------|--------|--------+ -| lxd.snap | https://127.0.0.1:8443 | lxd | tls | NO | NO | -+-----------------|------------------------------------------|---------------|-----------|--------|--------+ -| ubuntu | https://cloud-images.ubuntu.com/releases | simplestreams | | YES | YES | -+-----------------|------------------------------------------|---------------|-----------|--------|--------+ -| ubuntu-daily | https://cloud-images.ubuntu.com/daily | simplestreams | | YES | YES | -+-----------------|------------------------------------------|---------------|-----------|--------|--------+ - -``` - -Still, the default remote is **local**. That means that **./lxc** will not work yet. We need to make **lxd.snap** the default remote. -``` -$ ./lxc list -LXD socket not found; is LXD installed and running? -Exit 1 - -$ ./lxc remote set-default lxd.snap - -$ ./lxc list -... now it works ... - -``` - -### Conclusion - -We saw how to get a client to access a LXD server. A more advanced scenario would be to have two LXD servers, and set them up so that each one can connect to the other. - - --------------------------------------------------------------------------------- - -via: https://blog.simos.info/how-to-use-lxc-remote-with-the-lxd-snap/ - -作者：[Simos Xenitellis][a] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://blog.simos.info/author/simos/ -[1]:https://stgraber.org/2016/04/12/lxd-2-0-remote-hosts-and-container-migration-612/