Containerize fronted component #392

[Noa-limoy]

closes #392

I've created a Dockerfile for the frontend component, which allows for containerization of the frontend application. Currently, the frontend can only be run locally via the command line.
now we can run the frontend as a k8s workload resource, and its separate from the backend container.

Build the frontend image:

docker build -f Dockerfile -t nv2-frontend-dev .

The container image runs correctly and provides the same functionality as running the frontend locally:

docker run -it --rm -p 9001:9000 -v $(pwd):/usr/src/app nv2-frontend-dev

[andyatmiami]

In general - I think we want to approach the Dockerfile more geared to a production build of the frontend.

• ⚠️ We should verify this with the community - so please only take this as a discussion point for now!

By "production build" - I mean making sure the image is built deterministically and focused on being as small as possible.

• npm ci
• only install required dependencies
• NODE_ENV=production
• using multi-stage built to not leak dev/optional dependencies into image

Here is a rough outline of how I could see this Dockerfile structured given the above (but just use this is a discussion point for time being)

# Build stage
FROM node:20-slim AS builder

# Set working directory
WORKDIR /usr/src/app

# Copy package files
COPY package*.json ./

# Install ALL dependencies (including devDependencies)
RUN npm ci

# Copy source code
COPY . .

# Build the application
RUN npm run build

# Production stage
FROM node:20-slim

# Set working directory
WORKDIR /usr/src/app

# Copy package files from builder stage
COPY --from=builder /usr/src/app/package*.json ./

# Install only production dependencies
RUN npm ci --only=production

# Copy built assets from builder stage
COPY --from=builder /usr/src/app/dist ./dist
COPY --from=builder /usr/src/app/public ./public

# Create non-root user
RUN addgroup --system appgroup && \
    adduser --system appuser --ingroup appgroup && \
    chown -R appuser:appgroup /usr/src/app

# Switch to non-root user
USER appuser

# Expose the development port (matching webpack dev server)
EXPOSE 8080

# Set environment variables
ENV NODE_ENV=production
ENV PORT=8080

# Start the production server
CMD ["npm", "run", "start:prod"]

[google-oss-prow]

@andyatmiami: changing LGTM is restricted to collaborators

In response to this:

In general - I think we want to approach the Dockerfile more geared to a production build of the frontend.

• ⚠️ We should verify this with the community - so please only take this as a discussion point for now!

By "production build" - I mean making sure the image is built deterministically and focused on being as small as possible.

• npm ci
• only install required dependencies
• NODE_ENV=production
• using multi-stage built to not leak dev/optional dependencies into image

Here is a rough outline of how I could see this Dockerfile structured given the above (but just use this is a discussion point for time being)

# Build stage
FROM node:20-slim AS builder

# Set working directory
WORKDIR /usr/src/app

# Copy package files
COPY package*.json ./

# Install ALL dependencies (including devDependencies)
RUN npm ci

# Copy source code
COPY . .

# Build the application
RUN npm run build

# Production stage
FROM node:20-slim

# Set working directory
WORKDIR /usr/src/app

# Copy package files from builder stage
COPY --from=builder /usr/src/app/package*.json ./

# Install only production dependencies
RUN npm ci --only=production

# Copy built assets from builder stage
COPY --from=builder /usr/src/app/dist ./dist
COPY --from=builder /usr/src/app/public ./public

# Create non-root user
RUN addgroup --system appgroup && \
   adduser --system appuser --ingroup appgroup && \
   chown -R appuser:appgroup /usr/src/app

# Switch to non-root user
USER appuser

# Expose the development port (matching webpack dev server)
EXPOSE 8080

# Set environment variables
ENV NODE_ENV=production
ENV PORT=8080

# Start the production server
CMD ["npm", "run", "start:prod"]

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[andyatmiami]

Not implying anything wrong with this RUN statement to define a non-root user - but we should definitely align how we do this across controller + backend + frontend for sake of consistency.

Right now, backend + controller simply use hard-coded value of USER 65532:65532

(fwiw - I like this solution better - but def want consensus from the community at large!)

[Noa-limoy]

Yeah, I used the following method beacuse this approach is a bit more explicit and readable.
but I totally agree with you that consistency across the project definitely matters.
I’ll change it..

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign ederign for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• workspaces/frontend/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment