Now that docker support has reappeared in the latest FreeNAS 11.1 release, I wonder just where this is going in 2018. Public statements on the subject have been few and far between apart from what you might have picked up on here and there, e.g: https://redmine.ixsystems.com/issues/23393 Who exactly among FreeNAS users will be delighted at the decision to embrace rancher/rancheros?
Saying “Rancher brings a lot of advantages for containers, it has a nice UI called RancherUI and you can make an orchestration with lots of other containers just installing a simple agent. Also soon Rancher 2.0 will bring great user experience with Kubernetes whether managing it using Rancher or existing Kubernetes clusters.” sounds all well and good if you are involved in large scale deployment and development of containers across multiple hosts, but for someone interested in deploying a relatively small number of docker containers it’s a sledge hammer to crack a nut.
I wonder too if anyone who really needs all the functionality rancher/rancherUI provides would be happy to orchestrate their docker swarm from a virtual machine embedded in FreeNAS, especially when that new VM facility was described as “experimental” in one forum announcement and as currently implemented suffers for the severe limitation of not being able to upgrade the base rancheros. Rancheros is somewhat bleeding edge and like all Linux distros must surely respond to kernel security advisories even if there were no other bugs to be fixed. The need to upgrade is fundamental and there have already been two further rancheros releases in the last couple of weeks. ( see: https://github.com/rancher/os/releases)
This issue has been recognised and supposedly fixed for 11.2, but if this is the fix, it looks to have just hard coded the rancheros v.1.1.2 boot details for grub-byhve to use and is only good until the next rancheros version is released. (See: https://redmine.ixsystems.com/proje...ff149b558fda102e9bfb716561ef1ef4c6acf97a/diff)
The appearance of a “DockerVm” in FreeNAS 11.1 seems to have caused confusion in the minds of some user about its setup, due in part to the constraints of existing code. Unlike other VM setup, VNC devices are not supported, but the user is not prevented from selecting such a device and is only told it is invalid after the fact. Unlike other VMs where a zvol must first be created in your zpool, when setting up a “DockerVM” you need only supply the name of an img file which will be appended to the dataset mount path of your choice. This img file must not pre-exist, so that’s the exact opposite of other VMs. Incorrectly specifying the img file can leave the system with grub-bhyve using 100% cpu. There seems to be no sanity check here and no useful error messages. When starting the “DockerVM” for the first time the pre-built rancheros img is downloaded in the background and if for any reason is unsuccessful the user can be left unable to start a "DockerVM" without any idea how to get it to work. On starting a “DockerVM” for the first and subsequent times a message “Let the magic begin ...” appears. This seems to be more worthy of some script kiddie than a professional product and is hardly informative to the user.
The FreeNAS 11.1 guide gives the impression installing the rancher-server is natural further step in the set-up without mentioning other possibilities, nor does the guide make any reference to ways in which docker containers can be linked to zpool storage, an essential ingredient in making use of docker with FreeNAS.
Those keen to use docker since the demise of Corral have already found their own path, some have set up rancheros manually using iohyve, others have just installed docker and docker-compose in a Linux VM their choice, and portainer offers a simple UI for docker management. These users may have little incentive to use the new “DockerVM” function. Those who clung to Corral may finally look to move to the latest FreeNAS, but what have they made of the new “DockerVM” function?
I can’t help thinking that rancheros/rancher looks like a devs choice and may not be well suited to those who just want to get a couple of docker apps working as simply as possible.
Saying “Rancher brings a lot of advantages for containers, it has a nice UI called RancherUI and you can make an orchestration with lots of other containers just installing a simple agent. Also soon Rancher 2.0 will bring great user experience with Kubernetes whether managing it using Rancher or existing Kubernetes clusters.” sounds all well and good if you are involved in large scale deployment and development of containers across multiple hosts, but for someone interested in deploying a relatively small number of docker containers it’s a sledge hammer to crack a nut.
I wonder too if anyone who really needs all the functionality rancher/rancherUI provides would be happy to orchestrate their docker swarm from a virtual machine embedded in FreeNAS, especially when that new VM facility was described as “experimental” in one forum announcement and as currently implemented suffers for the severe limitation of not being able to upgrade the base rancheros. Rancheros is somewhat bleeding edge and like all Linux distros must surely respond to kernel security advisories even if there were no other bugs to be fixed. The need to upgrade is fundamental and there have already been two further rancheros releases in the last couple of weeks. ( see: https://github.com/rancher/os/releases)
This issue has been recognised and supposedly fixed for 11.2, but if this is the fix, it looks to have just hard coded the rancheros v.1.1.2 boot details for grub-byhve to use and is only good until the next rancheros version is released. (See: https://redmine.ixsystems.com/proje...ff149b558fda102e9bfb716561ef1ef4c6acf97a/diff)
The appearance of a “DockerVm” in FreeNAS 11.1 seems to have caused confusion in the minds of some user about its setup, due in part to the constraints of existing code. Unlike other VM setup, VNC devices are not supported, but the user is not prevented from selecting such a device and is only told it is invalid after the fact. Unlike other VMs where a zvol must first be created in your zpool, when setting up a “DockerVM” you need only supply the name of an img file which will be appended to the dataset mount path of your choice. This img file must not pre-exist, so that’s the exact opposite of other VMs. Incorrectly specifying the img file can leave the system with grub-bhyve using 100% cpu. There seems to be no sanity check here and no useful error messages. When starting the “DockerVM” for the first time the pre-built rancheros img is downloaded in the background and if for any reason is unsuccessful the user can be left unable to start a "DockerVM" without any idea how to get it to work. On starting a “DockerVM” for the first and subsequent times a message “Let the magic begin ...” appears. This seems to be more worthy of some script kiddie than a professional product and is hardly informative to the user.
The FreeNAS 11.1 guide gives the impression installing the rancher-server is natural further step in the set-up without mentioning other possibilities, nor does the guide make any reference to ways in which docker containers can be linked to zpool storage, an essential ingredient in making use of docker with FreeNAS.
Those keen to use docker since the demise of Corral have already found their own path, some have set up rancheros manually using iohyve, others have just installed docker and docker-compose in a Linux VM their choice, and portainer offers a simple UI for docker management. These users may have little incentive to use the new “DockerVM” function. Those who clung to Corral may finally look to move to the latest FreeNAS, but what have they made of the new “DockerVM” function?
I can’t help thinking that rancheros/rancher looks like a devs choice and may not be well suited to those who just want to get a couple of docker apps working as simply as possible.
Last edited:
