First Dev2FS release

NOTE: this article is pretty much technical, it touches subjects of: Linux Filesystem and Containerization (Docker)

Recently I released very first working version of Dev2FS. What is Dev2FS and why it has been developed for?
It is a FUSE based filesystem [Wiki]. It allows on mounting file resources like Linux filesystems do, but it does not handle very complex issues of data organization within a block device. Rather it is just a ‘cover’ for an existing file storage which introduces desired functions.

My professional work is testing and development of a Web Applications. I frequently use Docker containers, it allows on launching various application servers in isolated environment. So, I can experiment, test and very importantly ‘save’ a certain configuration for fast recreation later on.

Automation of a workflow is a key element for every business, thus, tool such a Docker come handy, but I found some missing elements.

UID:GID remapping

For development purposes (containerized) application server must share files with a host, so IDE can access code for editing and debugging purposes, as well as access data such as an image resources.
Volume sharing is one of the core functions of the Docker.

As mentioned, an automation is a key, therefore, I developed a set of scripts that run inside container to perform actions concerned with web app installation and configuration.
But, standard Apache uid:gid under which web application is deployed is 33:33 (www-data:www-data). Standard Linux user id is 1000. Bellow, you can find content of one of my projects, ‘app’ is shared with a container:

my user name is ‘barney’ (uid:1000, gid:1000). File docker-compose.yaml looks as bellow:

...

services: 
 ...
  webapp: 
    image: 200ms/prestashop_dev2
    ports:
      - 8080:80
    volumes:
      - ./app:/var/www/html/
...

Here is the issue, I’ve got nice automation inside docker but from host point of view app belongs to a different owner and group. It prevents IDE from modifying code, what is the must when it comes to development.
Frequent usage of ‘chown’ as root for every day work is not an elegant. In another hand setting up file permissions to ‘a+rw’ neither.

Hence, I was missing a tool that would do a simple remapping of permissions in ‘background’. As I did not found appropriate solution I decided to write it using FUSE and C.
Dev2FS “Dev Square FS” is complementing a set of Docker Images I called Dev2 “Dev Square”. Dev2FS is run inside container (at container’s root) with purpose to do remapping.
As an argument it takes ‘storage directory’ and ‘mount point’, like bellow:

dev2fs <storage directory> <mount point> -o <options>
e.g.:
dev2fs /code /var/www/html -o allow_other

‘/code’ is shared volume with a host e.g.: ‘docker …. -v $(pwd)/app:/code’
Option ‘allow_other’ allows no root users to access mount point, Dev2fs must be launched from container’s root (so it can access resources that belong to a various users).

Dev2FS follows a simple logic: every file within a mount point and storage directory shall inherit ownership of a parent. ‘/var/www/html’ is 33:33, ‘/code’ is 1000:1000, therefore files created within ‘/var/www/html/’ will be stored inside ‘/code’ with inherited 1000:1000 ownership. But presented in ‘ /var/www/html/’ with 33:33.

Hence, neither containerized Apache nor IDE is complaining about privileges. Messages such as “Error writing: Permission denied” that has been an issue before are gone.

Next step: Internal “mounts’ (under implementation)

The next feature (under development) is an internal ‘mount’. It is an answer for the case of developing Theme or Plugin/Module (WordPress, Prestadhop).
The code that matters in this case is a very small portion of the entire system (WordPress, Presta). Let’s say I develop Wordpres Plugin. In a project directory I would have ‘app’ folder for keeping WordPress source, and ‘src’ for storing plugin code.
‘app’ folder is not committed to git as it holds common WordPress source. But ‘src’ is traced with a code repository among README.md and other doc. files.
The plugin (‘src’ directory) must be accessible by application server under a certain path. In this case I would share code with container as follows:

...

services: 
 ...
  webapp: 
    image: 200ms/wpapache_dev2
    ports: 
      - 8080:80
    volumes: 
      - ./app:/mnt/app
      - ./src:/mnt/src
...

I want content of ‘/mnt/src’ (the plugin code) to be appeared under ‘/var/www/html’ mount point in a directory ‘wp-content/plugins/myfirstplugin’. Dev2FS would run with an additional parameter:

dev2fs /mnt/app /mnt/src:wp-content/plugins/myfirstplugin /var/www/html -o allow_other

Important note is that logic of Dev2FS shall ‘expose’ content of plugin only if the path ‘wp-content/plugins/myfirstplugin’ is created first. It is in a contrast to ‘typical’ mount where access path is available right after mount command.
I want such an behavior to ensure that installation script will not fail because of an unexpected content.

The code is committed here:
https://github.com/tools200ms/dev2fs

Note, the project is in a ‘Beta’ stage.