Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

OpenShift v4 compatibility #9245

Closed
rarkins opened this issue Mar 22, 2021 · 10 comments
Closed

OpenShift v4 compatibility #9245

rarkins opened this issue Mar 22, 2021 · 10 comments

Comments

@rarkins
Copy link
Collaborator

rarkins commented Mar 22, 2021

What would you like Renovate to be able to do?

Have its default images compatible with OpenShift v4 "out of the box".

Did you already have any implementation ideas?

Although the Renovate images are no longer built in this repo, I choose to create this issue here for maximum visibility. Previously OpenShift compatibility was added by @mikaelkolkinn in #4764. Past issues indicate both @patrickmarabeas and @alclonky were both Renovate and OpenShift users too at some point.

Is anyone using OpenShift v4 and has an idea if anything needs to change?

There is a big section about user IDs that was present in the v3 guide but missing in v4, including this part:

image

I've also seen someone mention elsewhere that you shouldn't create any user at all in OpenShift, which seems more strict than the "if you create a user then it will be ignored by OpenShift" understanding I previously had.

A comment here prior to v4 indicated that OpenShift would detect or not change $HOME, which could help us. Some of the package managers we use want to look for config in their home directory.

@rarkins rarkins added type:feature Feature (new functionality) help wanted Help is needed or welcomed on this issue priority-2-high Bugs impacting wide number of users or very important features status:requirements Full requirements are not yet known, so implementation should not be started labels Mar 22, 2021
@alclonky
Copy link

we are running on OpenShift v4 with the following fixes:

FROM whitesource/renovate:1.2.0

ENV APP_ROOT=/usr/src/app
WORKDIR ${APP_ROOT}
ENV HOME=/home/ubuntu
USER 0

COPY uid_entrypoint /

RUN usermod -a -G root ubuntu && \
     mkdir -p ${HOME} && \
     chown -R ubuntu:0 ${HOME} && \
     chmod -R g=u ${HOME} && \
     chown -R ubuntu:0 ${APP_ROOT} ${HOME} && \
     chmod -R g=u ${APP_ROOT} ${HOME} && \
     chmod g=u /etc/passwd && chmod ug+x /uid_entrypoint

USER 1000

ENTRYPOINT [ "/uid_entrypoint" ]
CMD [ "node", "src/server"]

uid_entrypoint:

#!/bin/bash
if ! whoami &> /dev/null; then
  if [ -w /etc/passwd ]; then
    echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/bin/bash" >> /etc/passwd
  fi
fi
exec /usr/local/bin/docker-entrypoint.sh "$@"

@viceice
Copy link
Member

viceice commented Mar 22, 2021

/home/ubuntu should already be owned by root group, so that change shouldn't required 🤔

@kolkinn
Copy link
Contributor

kolkinn commented Mar 22, 2021

I no longer work at the place where we used OpenShift, so I'm afraid I cannot help with verifying things.

@rarkins
Copy link
Collaborator Author

rarkins commented Mar 22, 2021

@alclonky that is fantastic help, thanks!

FYI renovate/whitesource:1.3.0 transitioned to use the renovate buildpack with this as the important bits:

FROM renovate/buildpack:4 AS buildpack
FROM ubuntu:20.04 as base
ARG USER_NAME=ubuntu
ARG USER_ID=1000
ARG APP_ROOT=/usr/src/app
ENV BASH_ENV=/usr/local/etc/env
SHELL ["/bin/bash" , "-c"]
COPY --from=buildpack /usr/local/bin/ /usr/local/bin/
COPY --from=buildpack /usr/local/buildpack/ /usr/local/buildpack/
RUN install-buildpack

<snipped tool installs>

WORKDIR ${APP_ROOT}
COPY package.json yarn.lock ./
RUN yarn install --production --frozen-lockfile
COPY src/server.js src/server.js
ENTRYPOINT [ "docker-entrypoint.sh" ]
CMD [ "node", "src/server.js" ]
EXPOSE 8080
USER $USER_ID

I'd be interested to know how much of your script you can remove before it stops working. The user/group/home/etc should already be there.

I had thought that OpenShift v4 should add /etc/passwd entries automatically, avoiding the need for your uid_entrypoint script, but maybe you found otherwise in practice?

@alclonky
Copy link

OpenShift seems to add the user to /etc/passwd https://www.openshift.com/blog/a-guide-to-openshift-and-uids. But the userid is random and in case of renovate this random userid has to have an home directory which he whould not get without the uid_entrypoint.

you can test this without OpenShift by running the container with random userids

@rarkins
Copy link
Collaborator Author

rarkins commented Mar 22, 2021

I got the impression that OpenShift would either (a) respect any configured $HOME if it exists, or (b) create it. We'd want to go with (a) if that's the case. Then we need to see if the tools all recognize this $HOME even if it's user 1238521351325 but HOME=/home/something

you can test this without OpenShift by running the container with random userids

I got the impression that OpenShift does a bunch of "stuff" before it executes a container so testing it without OpenShift can produce false confidence or negatives.

@alclonky
Copy link

OpenShift does nothing inside the container as far as I know. The /etc/passwd part was new for me but wont help because the user needs to get the $HOME which wont work without the entrypoint

I got the impression that OpenShift does a bunch of "stuff" before it executes a container so testing it without OpenShift can produce false confidence or negatives.

The $HOME and the permissions for $HOME for the random userid where the only Issues we had, and should be testable as I said. We are running renovate in OpenShift with this "workaround" since we started using renovate.

@rarkins
Copy link
Collaborator Author

rarkins commented Mar 22, 2021

My hope was that if HOME was already in the container and writable by group 0 then any random user should (a) know which home dir to use and (b) have sufficient access. It doesn't necessarily even need to be under /home either.

However we already have a custom entrypoint so hopefully no obstacle to adding whatever we need.

@rarkins
Copy link
Collaborator Author

rarkins commented Mar 22, 2021

This seems relevant: https://access.redhat.com/articles/4859371

Includes:

The OpenShift run-time CRI-O (starting from OpenShift 4.2 onward) now inserts the random user for the container into /etc/passwd. Removing the requirement to insert the random user manually into /etc/passwd completely. Additionally in future versions of CRI-O, the $HOME or $WORKDIR of the container user will also be assigned, helping Java based images (thanks Akram - see below).

@rarkins
Copy link
Collaborator Author

rarkins commented Apr 10, 2021

Proposal:

  • Always create /home/default, and make it writeable by GUID 0
  • Set $HOME to /home/default
  • Create a user, defaulting to UID 1000 and name user, because all non-OpenShift platforms will require this

Alternatively we could shift to default username default instead of user

@rarkins rarkins added priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others and removed priority-2-high Bugs impacting wide number of users or very important features labels Apr 10, 2021
@rarkins rarkins removed type:feature Feature (new functionality) help wanted Help is needed or welcomed on this issue priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:requirements Full requirements are not yet known, so implementation should not be started labels Oct 1, 2023
@renovatebot renovatebot locked and limited conversation to collaborators Oct 1, 2023
@rarkins rarkins converted this issue into discussion #24789 Oct 1, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants