Shulou(Shulou.com)06/01 Report--

This article introduces how to use colinux to make tinycolinx and build server farm and vps iaas environment instead of docker on ecs. The content is very detailed. Interested friends can refer to it and hope to help everyone.

This article keywords: tinycorelinux installed on the hard disk, custom tinycore linux kernel,tcl3 installation method,tcl installed on the hard disk, custom linux rootfs, use colinux instead of docker to form containers. Single port anti-generation reuse technology, intranet forwarding multiplexing port

An application of xaas: It can simulate docker containers and divide ECS into multiple sub-colinux systems. For example, for an ECS with 1C core and 1G memory, we can divide ECS resources into 512/128=4 colinux containers according to the granularity size of 128M. In addition to memory quotas, the tinycorelinux wiki also defines the ability of governors to limit CPUs and explains them. None of this takes advantage of docker's virtual hell drawbacks: docker, for example, uses a tiered federated file system that is difficult for users to maintain.

To achieve usability, we had to make a number of improvements. For example, since the 128m memory limit was too small, we had to leverage a dedicated colinux os distribution instead of the huge ubuntu etc., For example, tinycore Linux OS can exist with at least 10M server cores, which is the same reason that boot2docker on Windows uses a customized version of core Linux OS. Another consideration for choosing tcl is that it has a unique distribution package mechanism. Its distribution package is relatively simple. The dedicated software package distribution limit can prevent VM users from installing messy large software. Third, tcl's cloud run+ persistence mechanism (the whole root can be mounted to the memory livecd or other media, the home directory can be mounted, and tcz loop mounts must be mounted) makes it difficult to easily destroy the system even if the user root is given. Suitable for VM use.

For a real VM container environment, there are other advanced topics, such as an ECS with only one port 80, multiple intranet colinux VM environments need to reuse port 80 out of the network. Anyway, here's how to get tinycore and colinux together: make a streamlined tinycorelinux release for colinux.

Create a thin server distribution

All this needs to be done on another linux machine, such as colinux version 14.04:

At first, I tried downloading the latest iso by referring to the method of installing ubuntu8.04 iso to colinux on the Internet. I tried to enter it by directly mounting/dev/cobd1=xx.iso,root=/dev/cobd1,initrd= tinycore.gz in the conf file. I found that I could not enter it at last. There were colinux initrd problems, tinycore.gz file system problems, and colinux kernel problems. The CD format seems to be dead.

You don't have to reprogram the kernel or repackage rootfs, do you?

But in fact, hard disk mode plus + low version microcore3.8.4.iso is feasible, I re-made a 1G hard disk, in colinux mkfs.ext3 format it, copy the iso microcore.cpio directly released to the hard disk, tinycorelinux began to run until the login user prompt, i.e. cpio -idmv < microcore.cpio to the root directory, and then boot the new hard disk system with colinux (The original colinux vmlinux can be unmodified, initrd.gz can also be used), so naturally it is tinycorelinux hard disk mode. (After initrd.gz injection, restart again, prompt scatter harddisk installation mode and enter login prompt, use tc user to log in without password), I call it tinycolinux.

tinycolinux's conf can also support various bootcodes mentioned in tinycorelinux, such as root=/dev/cobd0,home=/dev/cobd 0,opt=/dev/cobd0,tce=/dev/cobd0 These, because tinycorelinux will search the/tce directory on the partition for the application download directory, so I also created a new one in\, otherwise the default options from tce-load -wi xxx will appear in/tmp/tce,(In hard disk mode, home,opt,root all appear under the root of the current hard disk. Create a/tce directory under/, which has the same effect as setting tce=/dev/cobd0 in conf).

Since everything is done on the hard disk, the entire file system is persistent, and there are no persistence issues to deal with except for application installation:

TinyCoreLinux Persistence Issues-User Data and Application Extension Retention

tinycorelinux initially positioned live iso and cloud mode, reflected in its ability to run in a variety of scenarios where liveiso is completely non-persistent, and persistent media, its root file system core set and application extension settings are fresh after each restart Restart loses all session and application extensions and its settings data, because everything is mounted to external persistent entries or loaded into ram tcz extension images, for the former, It is actually the entrance to mount to persistent media---because these are mount hook points, so you can concentrate on unloading, changes are still outside, for the latter, ram naturally can not last, both can maintain a clean environment after restart,

For persistence that must be carried over to the next reboot, or the entire file system, unless you specify save logic and define save entries--note this, which we'll get to later.

There are three configurable mountable directories,/home,/opt, and/tce. You can mount all three to persistent external media or choose one or two. Imagine that tcl starts with no persistent media at all. It has no persistence at all, but if you specify at least one persistent directory to external media and start it, it can save changes on external media, but these changes will not be carried to any other part of the root file system except these three parts.

In a special case, when tincorelinux's entire file system is placed on and booted from the hard disk, the entire hard disk is actually readable and writable (nostore bootcode is naturally enabled, and/home,/opt,/tce are ready-made persistent directories defined by default).

As for the part of persistence and changes that are carried over to the next reboot and root file system, you can specify restore: for example bootcodes defines restore, and/home to the hard disk and adds new entries in.filetool.lst, which produces mydata.tgz backups/home and/opt to this persistence--you can customize the persistent path including/home,/opt and the path where restore is specified in bootcode, perform filetool-b once, and be restored by the system the next time.

For applications, in the same way (as specified in bootcode above), there can be a directory defined in/tce that is stored on persistent media, such as hard disk, where changes to options and onboot.lst under/tce are persisted. *.tcz can be dynamically mounted (tcz is some read-only file system package, mounted in memory). Note here that the application load logic is persistent, but the application remains running in memory. And the settings part of the application has not been explicitly persisted.

So further, if tcz is to be brought into the system to make changes, you can still combine the.filetool tools and mechanisms to persist the parts of the specific tcz installation that need to be persistent to persistent or ln -s directories to hard disk, and you can also define the logic to boot using these directories for persistence in/opt/bootlocal.sh.

Make tinycolinux a complete hard disk system

So far, apps have been loaded into memory at once to run. For tinycolinux already installed, we need to install the application extension running purely on the hard disk:

(Although it's optimal for live systems and centralized maintenance of 3 directories, in fact, unless the application itself is customized, the application installation process may actually cause changes to the entire system file system, which is the default behavior of other linux distro packages), and I found that there are several packages different from tiny core linux, such as nginx and mysql, the former will generate loop mounts, the latter will not generate loop mounts, mysql installation tce-load -wi will stay in/usr/local target after installation, while nginx after-wi restart system only leaves some soft links, can not be unified processing, which instead caused trouble to the installation, in order to pursue a more natural class package management mechanism scheme and unified installation method, I came up with the method is initially directly download tcz package release to the target, Because the tcz package is a simple file system package, most of it is released to the usr/local directory and it is easier to install manually:

1) When downloading an app, only tce-load -w downloads to options

Circumventing tce-load -wi creates loop mounts. Use tce-load -w instead of installing.

2) Download http://mirrors.163.com/tinycorelinux/8.x/x86/tcz/squashfs-tools.tcz from this address, extract two executable files and put them in the root directory/bin

Use it for manual decompression.

3) Then look at the tcz content and use 7z to open it on windows to see where it is to be released.

The download address is often obtained by adding/3.x/tcz/package name.tcz to the entry in/opt/tcemirror, manually decompressing, unsquashfs -f -d / /tce/optional/nginx.tcz (here nginx is an example, it is released to/)

Tcz for deps, openssl and pcre for nginx. If all deps are installed or not found so file, restart a must find. sudo nginx will not find libprce.so.0

Then add an autostart entry to opt/bootlocal.sh,/usr/local/etc/init.d/openssh start for openssh and nginx -s start for nginx.

Done! Nginx automatically runs after restart! To uninstall, you only need to work with the/usr/local directory.

In fact, tcl this live mechanism can also be used to install instead of virtiope, this is later. In addition to these, when these colinux VMs are used to build stations, nginx is also required to reverse multiple VMs to reuse an 80 technology. In fact, when it comes to intranet forwarding multiplexing ports, the article "Building NAS based on colinux" can also be used to go out of the network. The two basic components of a manufacturing distribution, os itself, have been solved, and the toolchain problem. According to my article host 2 guest2host nativelangsys and cross compile system, although tinycore linux has the gcc application package, I tend to put it in windows hosts to compile and make tinycore linux usable targets. All right. I don't know.

About how to use colinux to make tinycolinx and build server farm and vps iaas environment on ecs instead of docker to share here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.