Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review and Document Dockerfiles #1019

Closed
krisnova opened this issue Jan 23, 2020 · 8 comments · Fixed by #1124
Closed

Review and Document Dockerfiles #1019

krisnova opened this issue Jan 23, 2020 · 8 comments · Fixed by #1124

Comments

@krisnova
Copy link
Contributor

Motivation

After mentioning deprecating docker images in #1015 I think this merits a holistic review of our Dockerfiles.

Feature

Can we please audit, and document which container images we are supporting, how each of them should be used, and assign owner(s) for them?

Alternatives

Additional context

@krisnova krisnova changed the title Review container images Review and Document Dockerfiles Jan 23, 2020
@krisnova krisnova added this to the 1.0.0 milestone Jan 23, 2020
@krisnova
Copy link
Contributor Author

From @mstemm in Slack 👍

a tailored build suitable for alpine linux would help a lot with making the container smaller and with a smaller potential set of dependencies. We’d have to build an .apk from source that links against musl libc, but once you had that, creating the image would be as simple as changing the base image to some alpine image and doing an apk add instead of dpkg -i

@krisnova
Copy link
Contributor Author

Another quick note, as #1024 starts to ramp up, we in theory should be able to drastically simplify our Dockerfiles

I think in a perfect world all a Falco dockerfile will do is use the in-house package manager to install Falco as it would on any other operating system.

@leodido
Copy link
Member

leodido commented Mar 12, 2020

Now that the main docker images have been refactored (PR #1059, #1063, #1069, #1076, etc) let's recap the current situation so to highlight what we still could/should do about them.

name (falcosecurity:...) directory scope auto build & push
falco-builder:latest docker/builder use it to build Falco (CI)
falco-tester:latest docker/tester use it to run Falco integration tests (CI)
to not be published docker/local built on-the-fly and used by falco-tester
falco:latest, falco:<tag>, falco:master docker/stable Falco (DEB built from git tag or from the master) with all the building toolchain
falco:latest-minimal, falco:master-minimal docker/minimal Falco (TGZ built from git tag or from the master) without the building toolchain
falco:latest-slim, falco:master-slim docker/slim Falco (DEB build from git tag or from the master) without the building toolchain
not able to find where it has been published docker/rhel
falco-event-generator:latest docker/event-generator Event generator tool to simulate events Falco catches
probe-linuxkit-4.9.184 docker/kernel/linuxkit to build and to insert the Falco kernel module on linuxkit kernel 4.19.184
probeloader:latest docker/kernel/probeloader to install the Falco kernel module by the mean of falcoctl install probe command

Some considerations:

  1. I'd remove the docker/rhel image because:
    1.1 I could not find it published somewhere
    1.2 It's based on rhel7 image and it'd make not straightforward for everyone to build and test locally

  2. I'd rename falcosecurity/falco-event-generator into falcosecurity/event-generator, then
    2.1 In case we decide as a community to keep this tool inside the Falco repository we should integrate its build and publish in the new release process (Move event-generator #1089)
    2.2 I'd personally move into in another repository, I'll propose a discussion about this in the next community call

  3. I'd remove probe-linuxkit-4.9.184 because:
    3.1 we now have driverkit to build the kernel module for linuxkit

  4. I'd remove probeloader because:
    4.1 does not seems to me the community is using it
    4.2 it simply wraps a falcoctl command
    4.3 it would be better to not have the side tooling like this in the Falco repo

  5. I think it is correct that falco-builder, falco-tester (and the docker/local image it builds on the fly) are not integrated into the release process because:
    5.1 they are development tools that needs to be manually pushed only when we update them
    5.2 the CI and the release process themselves rely on them to work

@fntlnz
Copy link
Contributor

fntlnz commented Mar 12, 2020

I agree with everything !! @leodido let's make it happen

@krisnova
Copy link
Contributor Author

krisnova commented Mar 12, 2020

I agree - like we said in slack I think we need to be aware of what we keep in the repository as we stage for our first LTS release of Falco

Also we mentioned renaming the probeloader on the last call - we should probably consider that as well as here.

Once we label something LTS we have to preserve some sort of backward compatibility (yet to be defined) so if we are deleting images and support - now is the time.

@leodido
Copy link
Member

leodido commented Mar 18, 2020

We need to review this page, and maybe merge in it what I wrote two comments above.

After that, and after we remove the unused docker images, I think we'll be able to close this.

@leodido
Copy link
Member

leodido commented Mar 18, 2020

FYI @Issif

@leogr
Copy link
Member

leogr commented Mar 30, 2020

I totally agree too. Furthermore, probeloader:latest might not work anymore because of falcoctl, and here we are discussing what falcoctl will do.
I will take care of fixing this asap
/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants