This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
manuals:vps:vpsadminos [2018/05/20 12:32] – created Aither | manuals:vps:vpsadminos [2021/11/12 19:42] – [Migration from OpenVZ to vpsAdminOS] odstraněna zmínka o tom, že vpsAdminOS není v Brně. KerryCZE | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | < | ||
====== vpsAdminOS ====== | ====== vpsAdminOS ====== | ||
- | Since [[information: | + | Since [[information: |
aren't supporting it, we had to find a way to upgrade our kernel, which | aren't supporting it, we had to find a way to upgrade our kernel, which | ||
meant choosing a different virtualization technology. Linux kernel now | meant choosing a different virtualization technology. Linux kernel now | ||
Line 30: | Line 31: | ||
- Developing vpsAdminOS into something usable | - Developing vpsAdminOS into something usable | ||
- Integration with vpsAdmin | - Integration with vpsAdmin | ||
- | - Opening of a staging environment with vpsAdminOS | + | - Opening of a staging environment with vpsAdminOS |
- Testing, fixing bugs, implementing missing features, preparing for production | - Testing, fixing bugs, implementing missing features, preparing for production | ||
- | - New production nodes are using vpsAdminOS, new VPS can be created only there | + | - New production nodes are using vpsAdminOS |
- Gradual migration of all VPS from OpenVZ nodes to vpsAdminOS, one node after another | - Gradual migration of all VPS from OpenVZ nodes to vpsAdminOS, one node after another | ||
- End of story | - End of story | ||
Line 46: | Line 47: | ||
===== Changes in VPS behaviour ===== | ===== Changes in VPS behaviour ===== | ||
- | ==== Network configuration ==== | ||
- | Linux kernel doesn' | ||
- | find a different way. Networking is done by a pair of veth interfaces: | ||
- | one on the host, the other in the VPS. IP addresses are routed through | ||
- | an interconnecting network that is assigned to every VPS. | ||
- | |||
- | For example, let's say the assigned interconnecting network is | ||
- | '' | ||
- | '' | ||
- | IP addresses are then routed via '' | ||
- | would be routed as '' | ||
- | in the VPS would be set as '' | ||
- | interface on the host is configured automatically by '' | ||
- | will also generate configuration files inside your VPS, depending on your | ||
- | distribution. The init system from your VPS will then read those files | ||
- | and setup the network interface. The first address on the interface will be | ||
- | the address from the interconnecting network, not the public address, as has | ||
- | been the case on OpenVZ. If you have some custom network configuration, | ||
- | you need to be aware of how the networking is supposed to work. | ||
- | |||
- | ==== User namespaces ==== | ||
- | VPS in vpsAdminOS are using so called //user namespaces// | ||
- | means that your system user and group IDs are mapped to different values on | ||
- | the host. For example, the root user in your VPS has UID 0, but from the | ||
- | host's point of view, its UID is e.g. 666000. Every member has been assigned a | ||
- | unique user namespace, which ensures that your data is isolated from other | ||
- | users. In case an attacker manages to leave the container, he will not be able | ||
- | to access data from VPS belonging to other members. | ||
- | |||
- | Every member is assigned a user namespace of 524288 user/group IDs. It means | ||
- | that you can use UID/GID from 0 to 524287. All VPS from one member are in the | ||
- | same user namespace. In the future, it will be possible to define custom | ||
- | UID/GID maps for VPS and NAS datasets, which will let each member to isolate | ||
- | his own VPS and yet share some chosen range of user/group IDs. | ||
- | |||
- | The user namespace significantly changes how you can share data between VPS | ||
- | and NAS. At the moment, it is **not possible** to mount NAS to a VPS running | ||
- | on a vpsAdminOS node so that you'd have access to the data. This will become | ||
- | possible when custom UID/GID maps are properly implemented. | ||
==== General ==== | ==== General ==== | ||
Changes regarding VPS, but independent on the distribution used: | Changes regarding VPS, but independent on the distribution used: | ||
- | * ''/ | + | * ''/ |
* Swap is not shown in ''/ | * Swap is not shown in ''/ | ||
- | * '' | ||
==== Debian/ | ==== Debian/ | ||
* Network is configured using '' | * Network is configured using '' | ||
- | * ''/ | ||
* If there is a directory called ''/ | * If there is a directory called ''/ | ||
===== Behaviour changes in vpsAdmin ===== | ===== Behaviour changes in vpsAdmin ===== | ||
+ | * NAS and snapshots are not accessed using vpsAdmin [[manuals: | ||
+ | * IP address management is split into routed and interface addresses | ||
* Reinstalling VPS on vpsAdminOS no longer deletes subdatasets and does not reset its configuration to the initial state, e.g. VPS features remain as they were. | * Reinstalling VPS on vpsAdminOS no longer deletes subdatasets and does not reset its configuration to the initial state, e.g. VPS features remain as they were. | ||
* VPS features: bridge, iptables and NFS aren't configurable, | * VPS features: bridge, iptables and NFS aren't configurable, | ||
Line 108: | Line 70: | ||
In order for all members to test VPS on vpsAdminOS, we've created so called | In order for all members to test VPS on vpsAdminOS, we've created so called | ||
staging environment. It's similar to playground, where everyone can create a | staging environment. It's similar to playground, where everyone can create a | ||
- | VPS. When creating a VPS, just select location **Staging** and the VPS will be | + | VPS. When creating a VPS, just select location **Staging** and deselect **Keep platform**. |
- | created on a vpsAdminOS node. | + | The VPS will be created on a vpsAdminOS node. |
It's terms of use are similar to [[manuals: | It's terms of use are similar to [[manuals: | ||
Line 117: | Line 79: | ||
resources among 4 VPS. | resources among 4 VPS. | ||
- | It is not possible to clone or swap production VPS with VPS in the staging | + | You can either create a new VPS or clone an existing |
- | environment. Migration | + | All mounts are removed when cloning, because NAS isn't acessible as of yet, |
- | Access to the NAS is also restricted, | + | see [[# |
- | + | ||
- | ==== Supported distributions ==== | + | |
- | * Alpine 3.6, 3.7 | + | ==== Features ==== |
- | * Arch | + | |
- | * CentOS 7.5 | + | |
- | * Debian 8, 9 | + | |
- | * Fedora 27, 28 | + | |
- | * Gentoo | + | |
- | * NixOS | + | |
- | * Ubuntu 16.04, 18.04 | + | |
- | ==== Other distributions ==== | + | Features can be turned on/off individually. When any change is made, the VPS restarts. |
- | In case your distribution isn't supported yet, you can help us make | + | {{ :navody: |
- | it happen, or wait until someone does it for you, see | + | |
- | [[https://github.com/ | + | |
- | Distribution templates installable from vpsAdmin are built using scripts at | + | * Docker (experimental) - Enables support for Docker. |
- | [[https:// | + | * FUSE - " |
- | If your distribution isn't there, it has to be added. | + | * KVM - " |
+ | * LXC nesting | ||
+ | * PPP - " | ||
+ | * TUN/TAP - "TUN routing/TAP bridging" | ||
- | When the built script is done, it is necessary to add support for your | + | We recommend only setting |
- | distribution into '' | + | |
- | resolvers, etc., see [[https:// | + | |
==== More about vpsAdminOS ==== | ==== More about vpsAdminOS ==== |