cloud-bulldozer / performance-dashboards

Performance dashboards from the Perf & Scale team
Apache License 2.0
16 stars 36 forks source link

Disconnected support #35

Closed jaredoconnell closed 2 years ago

jaredoconnell commented 2 years ago

Description

This PR successfully makes it so the dashboard templates are loaded into the syncer image, so that they can be deployed at runtime without cloning this repository.

The downside to this change is the syncer image needs to be updated for each PR, so that must be setup on quay.io

jaredoconnell commented 2 years ago

This PR is a bit confusing IMO. With the new changes, the syncer image expects the dashboard to be rendered in the localhost before copying them into the image, I think we should take advantage of a multi-stage Dockerfiles to build this container image and prevent pulling dependencies in runtime and building the dashboards in localhost: i.e

FROM registry.access.redhat.com/ubi8/ubi-minimal as builder
RUN microdnf install git make tar
RUN git clone https://github.com/cloud-bulldozer/performance-dashboards.git --depth=1
RUN make -C performance-dashboards build

FROM registry.access.redhat.com/ubi8/ubi-minimal
WORKDIR /dittybopper-syncer
RUN chmod 775 /dittybopper-syncer
COPY --from=builder /performance-dashboards/rendered/* .
COPY entrypoint.sh /bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]

I will change it to a multi-stage build to remove the Git dependency. Do you want the jsonnet rendered on container build, increasing image size, or when it's run, reducing it? Unless the make dependency exceeds the size of the rendered jsonnet.

rsevilla87 commented 2 years ago

This PR is a bit confusing IMO. With the new changes, the syncer image expects the dashboard to be rendered in the localhost before copying them into the image, I think we should take advantage of a multi-stage Dockerfiles to build this container image and prevent pulling dependencies in runtime and building the dashboards in localhost: i.e

FROM registry.access.redhat.com/ubi8/ubi-minimal as builder
RUN microdnf install git make tar
RUN git clone https://github.com/cloud-bulldozer/performance-dashboards.git --depth=1
RUN make -C performance-dashboards build

FROM registry.access.redhat.com/ubi8/ubi-minimal
WORKDIR /dittybopper-syncer
RUN chmod 775 /dittybopper-syncer
COPY --from=builder /performance-dashboards/rendered/* .
COPY entrypoint.sh /bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]

I will change it to a multi-stage build to remove the Git dependency. Do you want the jsonnet rendered on container build, increasing image size, or when it's run, reducing it? Unless the make dependency exceeds the size of the rendered jsonnet.

Only the "build" container size will increase, the resulting container image will be small

jaredoconnell commented 2 years ago

This PR is a bit confusing IMO. With the new changes, the syncer image expects the dashboard to be rendered in the localhost before copying them into the image, I think we should take advantage of a multi-stage Dockerfiles to build this container image and prevent pulling dependencies in runtime and building the dashboards in localhost: i.e

FROM registry.access.redhat.com/ubi8/ubi-minimal as builder
RUN microdnf install git make tar
RUN git clone https://github.com/cloud-bulldozer/performance-dashboards.git --depth=1
RUN make -C performance-dashboards build

FROM registry.access.redhat.com/ubi8/ubi-minimal
WORKDIR /dittybopper-syncer
RUN chmod 775 /dittybopper-syncer
COPY --from=builder /performance-dashboards/rendered/* .
COPY entrypoint.sh /bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]

I will change it to a multi-stage build to remove the Git dependency. Do you want the jsonnet rendered on container build, increasing image size, or when it's run, reducing it? Unless the make dependency exceeds the size of the rendered jsonnet.

Only the "build" container size will increase, the resulting container image will be small

It will also increase by the size of the rendered dashboards, but I'm guessing that's not too much in the greater scheme of things.

jaredoconnell commented 2 years ago

The latest commit splits it into a two stage build. The new container is now less than half the size of the old one, and it no longer has any security vulnerabilities. It needs to be built from the root of the project.