This is the default boot mode of the .iso images, and setup-alpine configures this if selecting to install to “disk=none”. It means that the whole operating system and all applications are loaded into the RAM, and run extremely fast (saving unnecessary disk spin-ups, power, and wear). Still, customized configurations and package selections may be preserved on permanent storage media by using the “local backup utility” lbu and a local package cache. [Fixme: setup-alpine still needs this detour to prepare a partition for this.] In setup-alpine, select to store configs and the package cache on a partition. (That mounted partition may later also be used by configuring some important applications to keep their data on it.)
Data Disk Mode
This mode is still accelerated by running the system from RAM, however swap storage and the whole /var directory tree gets mounted from a persistent storage device (two newly created partitions). This location holds e.g. all log files, mailspools, databases, etc., as well as lbu backup commits and the package cache. The mode is useful for having RAM accelerated servers with amounts of variable user-data that exceed the available RAM size, and to let the entire current system state (not just the boot state) survive a system crash according to the particular filesystem’s guarantees. [Fixme: Storing lbu configs to disk is not auto-configured after configuring the data partition, one still has to select saving configs to “none” first (the new data partition is not listed), and to manually set e.g. LBU_MEDIA=sda2 in /etc/lbu/lbu.conf and execute echo "/dev/sda2 /media/sda2 vfat rw 0 0" >> /etc/fstab afterwards, to have the partition (here sda2) used.] The boot device may remain to be the one initially used, and can even be immutable (read-only).
System Disk Mode
This is a traditional hard-disk install. If this mode is selected, the setup-alpine script defaults to create three partitions on the selected storage device, /boot, swap and / (the filesystem root). This mode may be used for generic desktop and development machines, for example.
When they got the testnet I will try to get it fully working on docker image. What I noticed is that some files while building were not available so need to see how to fix the persistence.
Basically want the image to install alpine linux and at the same time create a persistent file that holds the .safe folder with the cli/node/etc files so you will always have your credentials when running the container again. Also that if you update the cli or node that it will be reflected in the persistent volume.
I was unable to expose my 12000 port to local network so far, don’t know if the network device is able to bridge from the docker instance to local host, should be a simple masquerade from host to the running docker image.
$ docker build -t safe_node .
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=safe_node&target=&ulimits=null&version=1": dial unix /var/run/docker.sock: connect: permission denied
Should the docker daemon be run as user or run as root?
Best practices says it should be run as a user. Normally, installing docker creates a linux group you need to add your user to for elevated privileges for something like this.
If it’s a throwaway machine you don’t really care about and you just want to get something working, you can run it as root to avoid potential permission issues.
I think Alpine Linux is one of the last distributions I would use to develop. It’s a great distribution, but it’s very minimalistic for a reason. I would guess you will bump into more problems like the one you’re getting now.
If you want a minimalistic distribution though, I can’t recommend Arch Linux enough.
I see only one operating system, so I’m not running another OS inside the container, correct?
Then I look at the code at the top post, I see FROM alpine:latest.
Alpine Linux it is.
No, you actually are running another OS inside the container. That “alpine:latest” is saying for X container, download this base image to run. Alpine is used for containers because it is very lightweight, which makes it great for containers, but not really super user friendly for stuff like this.
You can run Docker on any Linux distro (or even Windows).
Hmm
You’re free to run any other Linux inside of your docker containers…
I’m just a user of docker not a docker (itself) developer… I think the kernel (or certain parts) are being shared but it’s really not a problem to use Ubuntu for development and then use an alpine image for your applications
Hmhmm - tbh I don’t know anything about using graphics in containers but to me the main difference between vms and containers is that the barrier between host and guest is not that huge… The two are pretty tightly coupled (you can even see processes running inside of containers when you do a ‘htop’ on the docker host)… I use them as lightweight VMs…
Talking specifically about Linux, VMs generally run their own Linux kernel independent of the host OS (There are some exceptions like with Xen VMs). They are essentially emulated self contained running systems.
Containers, on the other hand, share the kernel with the parent OS (This is why Windows requires Windows Subsystem for Linux to be installed prior to using Docker). Containers are closer to encapsulated and walled off applications than a true VM, not so different from a chrooted environment with some network masquerading thrown on top.
