+= Dockerfile and updated README.md

[gww-fuel]

I am Nix/NixOS newbie, I hope this PR will be inspiration for someone to make nice Docker to build everything inside (i.e. not requiring any tools on host, e.g. hix) or eventually opportunity for me to learn through code review process. Or maybe that's good enough Dockerfile to start with 🤞 .

Try:

git clone https://github.com/FuelLabs/fuel.nix.git
cd fuel.nix
git fetch origin gww-fuel/dockerfile
git checkout -b gww-fuel/dockerfile origin/gww-fuel/dockerfile
grep docker README.md  # to have cheatsheet of docker commands
docker build -t fuel-nix -f docker/Dockerfile .  # build
docker run -it -v $(pwd):/pwd fuel-nix   # and inside docker `cd /pwd`

[kayagokalp]

Hey @gww-fuel thanks for the PR! Sorry I haven't been able to come to this repo for some time. Generally using nix would mean you don't have to deal with docker files since it will generate you the build environment you need. I guess this is for getting nix itself which makes sense. So given that nix flake itself is self sufficient in building stuff, we can get away with only installing nix and calling the flake which is what you did in this PR so we can merge this.

There are things that we can improve (for example nix flake itself can accept different suffixes for different derivations, this can be enabled through the docker file itself too) but, for nix user a docker file would be irrelevant so this is more towards non-nix users to quickly spin up something, so I think it makes sense to keep this as it is, (only getting the default derivation from the flake etc) cc @JoshuaBatty

utACK, I will be testing it locally in couple of hours as well.

[gww-fuel]

Thank you for change and feedback!

I am new to Nix,and happy to get better at this.

I consider two topics orthogonal:

• as Nix I consider in this scenario Provisioner,
• and docker a Provider (using Vagrant terminology).

One takes care to configure things,
the other takes care how how to isolate and execute them.

However if Nix allows for network namespace, process namespace, syscalls and other dimensions of isolation I would love to learn about it!

(
Topic of isolating programs running in Docker for security purposes, is explored here:

• https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc - bash functions wrapping calls
• https://github.com/jessfraz/dockerfiles - docker files for above file
• https://youtu.be/cYsVvV1aVss - lecture by Jess Fraz about using "Docker as a Desktop" to run everything in Dockers with increased isolation.

---

Probably it is topic for dedicated ticket to offer users script that has all docker flags configured to run fuel.nix with absolute minimum permissions required
)

To sum it up, here the use of docker is to provide maximum usability for users for deployments (as dockers are widely supporter), and even more, to provide convenient way to enable different levels of isolation mechanisms for enhanced security.

[JoshuaBatty]

Sorry I haven't had time to properly think about this. Just requesting changes to pause this getting merged before I come back to this early next week.

[JoshuaBatty]

Sorry this has taken me so long to reply to. While I can sympathise with why using docker in this circumstance could be useful to a certain type of developer, I am weary about including this information in the documentation for this repo.

The target audience for this repo specifically is existing nix users who are already using it to manage system dependancies. As such, I'd prefer if our documentation didn't splinter into trying to be more than this.

I'm still open to the idea of having this information hosted somewhere, but I think that needs to be part of a larger decision.

[gww-fuel]

Sure! What about keeping in sub-directory docker/ both docker/Dockerfile and dedicated docker/README.md where will be explained "This is for people who like to build with fuel using docker?

Also for people who isolate their build environments or like to make CI/CD pipelines, do we want them to not use fuel.nix and use only https://github.com/FuelLabs/fuelup directly ?
I am interested to explore adding PR to fuelup repo with Dockerfile for fuelup, still I thought that we would like to maintain fuel.nix long term and making it accessible and useful?

Of course we can have separate repo https://github.com/FuelLabs/Dockerfiles , if that's what you had in mind. It's just against common practice. Its like someone making separate repository https://github.com/FuelLabs/Makefiles for Makefiles from other repositories... still doable if there is such preference.

So, should I go ahead and undo changes to /README.md and make appropriate /docker/README.md that clarifies that this is for convenience for people that really want it?

I have to admit that without Dockerfile in this repository, and zero Nix experience, it took me time to make one that would work, and thought that making it easy for other enthusiasts who would like to embrace and play with Nix and experiment is inviting and helpful.

[JoshuaBatty]

Hi @gww-fuel sorry for the late reply.

Also for people who isolate their build environments or like to make CI/CD pipelines, do we want them to not use fuel.nix and use only https://github.com/FuelLabs/fuelup directly ?

Yes I think that makes the most sense. I think this PR makes more sense against the fuelup repo rather than this one. I'm going to close this PR for now but feel free to open a similar one over there. Although I can sympathise with the intention here, I think having a docker file to experiment with nix itself is beyond the scope of what we should offer and instead, this repo should just be for users that are using nix as their system package manager already.

[gww-fuel]

Thank you for taking a look!

One of reasons how this PR originated, was confusion if fuel.nix and fuelup are considered with same focus two possible toolchain managers, and two different for e.g. failover of alternative implementation.

Given answer it sounds like fuelup is considered to be main focus, and fuel.nix only for nix users, therefore makes total sense to make Dockerfile against fuelup to incentivise wider use and focus on main toolchain manager.