You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First i suggest that the name should be docker2fl or docker2fungi, to not be confused with the older flist format.
The tool goal is to make it easier to build fl files from any docker image. IMHO the tool can be written in rust, this way it can very easily import and use the rfs library directly to create the fl, otherwise you will have to relay and use an external rfs binary to do so.
In general the process of the conversion has to go like this
Someone builds a docker image (using Dockerfile) or whatever
The docker2fungi tool will then save the image with docker save command this saves the image to a .tar file.
I have built a shell script that can extract this tar file to a directory that contains the extracted files here. Of course the tool can easily implement this itself, and not use the script 🤷🏼♂️
Once the dir is extracted, the rfs tool can be used to pack the directory creating the fl. Again i think it's really better to embed rfs library in the tool itself, (hence build the full thing in rust). Check first the rfs command line to see how to use @Omarabdul3ziz can help with that one. And I of course if u have questions
NOTE: docker save can also output the tar to stdout it means the tool can directly untar the tar stream directly to a dir without the need to save it to disk first.
That is "almost" it.
But, there is an undocumented feature that is done by the current hub docker2flist. Since docker image also has meta about, entrypoint and env. which is not natively supported by the fl format (since the fl/flist format are mainly implementing the filesystem layer). The hub on conversion creates an extra file at the root of the directory before packing called .startup.toml this file is only used by zos if you going to run a workload. This file defines the default entrypoint and default env. The entrypoint can then be overridden by the deployment entrypoint if needed. The 2 envs (from the flist, and from the deployment) are merged.
Sample content of the file
[startup]
[startup.entry]
name = "core.system"
[startup.entry.args]
dir = "/"# workind dir as defined by the image metaargs = ["init"] # all the following args to the entrypointname = "zinit"# only name of the entrypoint binary
[startup.entry.args.env]
# list all env varsPATH = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
All toml entry names must be preserved. All the values that u need to set are values under startup.entry.args and startup.entry.args.env.
The text was updated successfully, but these errors were encountered:
First i suggest that the name should be
docker2fl
ordocker2fungi
, to not be confused with the olderflist
format.The tool goal is to make it easier to build
fl
files from any docker image. IMHO the tool can be written in rust, this way it can very easily import and use therfs
library directly to create the fl, otherwise you will have to relay and use an externalrfs
binary to do so.In general the process of the conversion has to go like this
docker save
command this saves the image to a.tar
file.directory
that contains the extracted files here. Of course the tool can easily implement this itself, and not use the script 🤷🏼♂️rfs
tool can be used topack
the directory creating the fl. Again i think it's really better to embedrfs
library in the tool itself, (hence build the full thing in rust). Check first the rfs command line to see how to use @Omarabdul3ziz can help with that one. And I of course if u have questionsThat is "almost" it.
But, there is an
undocumented
feature that is done by the current hub docker2flist. Since docker image also has meta about, entrypoint and env. which is not natively supported by the fl format (since the fl/flist format are mainly implementing the filesystem layer). The hub on conversion creates an extra file at the root of the directory before packing called.startup.toml
this file is only used by zos if you going to run a workload. This file defines the default entrypoint and default env. The entrypoint can then be overridden by the deploymententrypoint
if needed. The 2 envs (from the flist, and from the deployment) are merged.Sample content of the file
All toml entry names must be preserved. All the values that u need to set are values under
startup.entry.args
andstartup.entry.args.env
.The text was updated successfully, but these errors were encountered: