search

GoogleCloudPlatform / ruby-docker

Ruby runtime for Google Cloud Platform
Apache License 2.0
134 stars 56 forks source link

Support for a Maintained Version of NodeJS #240

Closed eric-hemasystems closed 4 months ago

eric-hemasystems commented 7 months ago

Looks like the containers are still stuck at 16.15.0 from when they were upgraded almost 2 years ago. Seeing as Node v16 has been EOL for about 5 months now, would it be possible to update to a newer version of Node? Looks like v20 is LTS with EOL being on 2026-04-30.

Not only is there the obvious security concern, I'm also having to pin more and more packages to an old version to have something that can still run on GCP.

MuhammetDilmac commented 4 months ago

I agree with you. I can't update vite version because of that.

eric-hemasystems commented 4 months ago

I'm actually going to close this. Looks like this whole repo is legacy. We recently started getting a message when deploying that says:

WARNING: ruby 3.1 and earlier versions will reach end of support on 2024-07-10 for App Engine flexible environment. After 2024-07-10, you cannot deploy new or re-deploy existing applications that use runtimes after their end of support date. We recommend that you migrate to the latest supported version of ruby.

This confused me as we were running on Ruby 3.3 (although it compiled it every time per #231). Finally looked into it more and it seems GCP has deprecated this whole process in favor of something built on buildpacks. You can find this in the docs where it says:

For version 3.2, you must include the runtime_config and operating_system settings in your app.yaml file to specify an operating system.

Evidently this is something they introduced in the last few years but since they didn't communicate it well I was completely unaware that the setup we had was legacy and soon to be no longer working.

The good news is the new buildpack stuff is better due to being both faster (it is smarter about building containers than the old setup) and using newer software. The downside is it is more complex (mitigating part of the advantage of GAE) and less flexible. For example if you need to install custom Ubuntu packages you could do so before via the runtime_config.packages config in app.yaml. That no longer works and those same docs say if you need to use custom packages you:

you will need to use a custom runtime based on this runtime to install the appropriate packages.

Doing a custom runtime means your all on your own for maintaining a dockerfile which seems like a pretty heavy price if you just need a few packages installed. The GAE docs don't really mention it but I did find you can customize the buildpack stuff. Since GAE is built on the GCP buildpacks this gives you a bit of the best of both worlds. You are still using the GCP buildpack stuff for the most part. But you have the option to install packages during the build process or for the runtime. This does bring some more complexity but still less than maintaining your own Dockerfile.