[universal] - Issue universal config change for non-root default codespace user and installing google chrome browser reuse sandbox to run puppeteer cli in universal image

[Kaniska244]

Ref: https://github.com/devcontainers/internal/issues/247
https://github.com/devcontainers/internal/issues/249

Dev container name:

Universal

Description:

We can determine UID of host machine via id -u & id -g and pass it to docker while building the image. Modified devcontainer.json as below resolved the issue.

Changelog:

For Universal UID permission issue

• Updated GitHub workflows to determine UID of host machine via id -u & id -g and pass it to GITHUB_ENV & updated devcontainer.json file to read the UID & GID from localEnv.

For puppeteer library issue

• Updated setup-user local feature to install chrome & also changed the devcontainer.json to populate a specific env variable in the remoteEnv, required for puppeteer library.

Checklist:

• Checked that applied changes work as expected.

[Kaniska244]

Hi @ddoyle2017 ,

Tested another workaround for this instead of forcing the UID 1001 as that was increasing the size of the image considerably.

• Setting "updateRemoteUserUID" flag to false so that UID & GID aren't replaced, so that the UID & GID of codespace user remains 1000.

• Adding "postStartCommand" to change the ownership of /workspaces/images folder to the same as of the codespace user, not using "postCreateCommand" option as its already used in other sub-features in universal image. This folder is directly mounted from the local machine containing the images repo sources.

• Tests are fine with this. Also tested locally in a codespace along with the devcontainer CI pipeline.

Would you kindly review the same. Please let me know in case of any concern.

With Regards,
Kaniska

[ddoyle2017]

Almost there! Can we revert the puppeteer --no-sandbox changes and rerun the Actions?

[Kaniska244]

Hi @ddoyle2017 ,

I have tested one fix for the puppeteer cli issue. Uploaded the fix. Would you kindly review the same & let me know in case of any concern.
Please note the change is only in the test script as the purpose of the test is to demonstrate that its possible to run a puppeteer node app in the universal container.

PFB the details:

• The actual issue was that there was no sandbox available to launch the browser when runner image is on ubuntu-24.04.
• Downloaded google chrome amd64-deb variant latest stable version & installed the same in the container.
• Chrome is shipped with a default sandbox, copied the same & populated this CHROME_DEVEL_SANDBOX variable which is used by the puppeteer by default.
• All tests are fine with this & this appears to be the safest approach compared to the other approaches which would require to launch the browser directly in the container without the sandbox or modifying the kernel to allow unprivileged access.

Ref - https://github.com/puppeteer/puppeteer/blob/88ef09c6ccc27d024972725c728a9db50f010f36/docs/troubleshooting.md#setting-up-chrome-linux-sandbox

With Regards,
Kaniska Sengupta

[ddoyle2017]

I think this is a reasonable work around for the Puppeteer issues with Ubuntu 24.04! Can you add a comment above both your changes to explain what issue they're solving?

[ddoyle2017]

hey @Kaniska244, so @eljog and I had a discussion about how to move forward with the release and I think we need to reorganize your changes for Puppeteer.

Currently, your Chrome workaround works for our CI test, but Puppeteer will still be broken for users of this image. We should apply your updates to the image as a whole (not just in test.sh), then see if that fixes the issue 👍

[Kaniska244]

hey @Kaniska244, so @eljog and I had a discussion about how to move forward with the release and I think we need to reorganize your changes for Puppeteer.

Currently, your Chrome workaround works for our CI test, but Puppeteer will still be broken for users of this image. We should apply your updates to the image as a whole (not just in test.sh), then see if that fixes the issue 👍

Hi @ddoyle2017 ,

I have made the changes according to the comments & all tests are fine with this. Would you kindly review the latest change.
PFB the details of the change.

• Changed the postStartCommand option to postCreateCommand as per the review comments.
• Made change in Dockerfile to install three more libraries which are required to install chrome.
• Made change in install.sh of the local feature setup-user to install chrome & placing the sandbox in the desired location. Please let me know if I should introduce a new local feature for this instead.
• Made change in devcontainer.json to configure "remoteEnv" tag for the CHROME_DEVEL_SANDBOX variable with the sandbox location which is used by the puppeteer library while launching the browser.
• Size of the image has now increased considerably due to the chrome installation which is still within the configured threshold but only by about 64 MB. With the previous change the gap was about 422 MB.
• Added comments on top of the changes for more clarity.

With Regards,
Kaniska

[Kaniska244]

Hi @ddoyle2017 , Hi @eljog ,

I have made further changes on the solution of the UID issue after consulting with @Mathiyarasy in order to achieve more clean, error-proof solution. Would you kindly review the same.

PFB the details of the changes:

• Changed the GitHub action workflows(universal smoke test & all the build and push workflows) to copy the UID & GID of the host & set it as environment variable.

• Changed the devcontainer.json to read the environment variables for UID & GID instead of hardcoding them to 1000.

• In case if the environment variables aren't set, the UID & GID are defaulted to 'automatic' option in common-utils feature which creates the user & group with the default available UID & GID as 1000. The build doesn't fail in that case as I tested in my local where the build was manually triggered, not by workflow.

• Made changes in all of the build & push workflows to fetch the UID/ GID and set the environment variables. However not able to test them independently in the forked repo so far. Same change works fine for smoke test universal workflow.

• The image size is also back within the configured threshold with this change.

• Also kindly note that jekyll smoke test is failing but I see it has already been failing with the same, so not related to this.

Please let me know in case of further concerns with this latest change.

With Regards,
Kaniska

[ddoyle2017]

Changes look good 🚀 I think this approach makes sense, based on Option 3 of Chromium's recommended AppArmor workarounds

[chrmarti]

Left a few questions.

[chrmarti]

Great, thanks!