Docker image improvements and Makefile targets

[alchzh]

Authored by @Jepson2k

• I have reviewed the OFRAK contributor guide and attest that this pull request is in accordance with it.

One sentence summary of this PR (This should go in the CHANGELOG!)
Fix small issues with Docker images and add Makefile targets for creating/starting them.

Link to Related Issue(s)
#547

Please describe the changes in your request.

• Reorder packages so ofrak_patch_maker comes first for better caching.
• Add Makefile targets ofrak-, start-ofrak-, and super-start-ofrak-* for creating/starting Docker images
• Change entrypoints in some docker images to auto accept the license (is this what we want to do? See Fix ofrak-dev, ofrak-ghidra, ofrak-tutorial entrypoints #547)

Anyone you think should look at this, specifically?

[rbs-jacob]

I do not think we should move forward with most of the changes in this pull request.

• The Makefile comments almost exclusively add noise, and are redundant – we don't need a comment for a single command that is the same length as the comment describing it
  • In general, comments should document why decisions were made, not what the code is doing
• The license terms need to be manually agreed by a user – there should not be code in the Makefile or entrypoint to automatically agree
• Many of the complex Makefile functions should not be in the Makefile at all – part of the reason we have build_image.py is to avoid complex, hard-to-maintain logic in Makefiles and shell scripts

The only change that might be alright is changing the order of ofrak_patch_maker in the YAML files, and I'm hesitant about that. It would be good for caching, but the order in which OFRAK packages are installed in Docker impacts whether the OFRAK version we are trying to build from source gets overridden by the pip version. We need to manually confirm that this is not happening in the images that get built before I am okay with moving ahead on this particular subset of the proposed changeset.

[ANogin]

The only change that might be alright is changing the order of ofrak_patch_maker in the YAML files, and I'm hesitant about that. It would be good for caching, but the order in which OFRAK packages are installed in Docker impacts whether the OFRAK version we are trying to build from source gets overridden by the pip version.

Yes. the order in yaml must agree with the dependencies.

We need to manually confirm that this is not happening in the images that get built before I am okay with moving ahead on this particular subset of the proposed changeset.

We need to finally land #218, then the check would no longer have to be manual.

[Jepson2k]

@rbs-jacob I can remove the comments and the setup.py related commands but otherwise I think the rest of the changes are worthwhile. The current method for downloading, building, and running ofrak in a container as outlined by the documenta is cumbersome. Moreover there is no easy way to run the tests locally that are ran on the remote (github) without examining the test-all.yml. Which again, in my opinion, is cumbersome. Users shouldn't have to have a deep understanding of the ofrak build system in order to simply build and run it in a container.

Take the following two key changes for example:

.PHONY: ofrak-%
ofrak-%: ## Build OFRAK image using ofrak-<name>
	@echo "Building OFRAK image using config: ofrak-$*.yml"
	python3 build_image.py --config ofrak-$*.yml --base --finish

.PHONY: start-ofrak-%
start-ofrak-%: ## Start OFRAK image using ofrak-<name>
	make ensure-ofrak-license image_name=$*
	@echo "Starting OFRAK image using config: ofrak-$*.yml..."
	docker run \
	  --rm \
	  --detach \
	  --hostname ofrak \
	  --name ofrak-$* \
	  --interactive \
	  --tty \
	  --publish 8877:80 \
	  --volume $(PWD)/ofrak.license:/ofrak.license \
	  redballoonsecurity/ofrak/$*:latest

I would argue these are barely more complex than the normal commands that the user would execute to build and run ofrak in a container. For example if a user wanted to use the ofrak-dev.yml config file they would either need to edit the existing makefile or run:

python3 build_image.py --config ofrak-dev.yml --base --finish
docker run --rm --detach --hostname ofrak --name ofrak-dev --interactive --tty --publish 8877:80 --volume $(PWD)/ofrak.license:/ofrak.license redballoonsecurity/ofrak/dev:latest

Theres a fair number of unintuitive arguments for each command as shown by the fact that we have a ~600 word documentation section just to describe the two commands needed to build and run docker. But by adding these to the Makefile we simplify it for the user such they they would only have to run:

make ofrak-dev
make start-ofrak-dev

Moving patch_maker to the top beginning of the yaml made a big difference in how often that layer's cache becomes invalidated by changes in other layers. Given the time required to download and build this stage (easily ~30 minutes on some systems), this small change makes a big difference. If the order of the yaml matters, we should clearly document it and explore other ways of keeping patch_maker's layer cache from becoming invalid.

As for the licensing it requires the user to have generated the ofrak.license file, a step that is automatically invoked if the file is missing when the user runs either of the start commands. This brings up the ofrak license prompt and requires the user to select the license agreement and type "I agree" in order for it to copy the ofrak.license file out of the docker container and continue successfully with the rest of the command. If this method is not satisfactory please propose a new method that doesn't require the user to type "I agree" every time they start a container.