Hope this isn't a stupid question. When looking at Docker images, particularly from the official repository they list multiple versions and labels for each dockerfile. For instance:
9.1.6-php8.0-apache-buster, 9.1-php8.0-apache-buster, 9-php8.0-apache-buster, php8.0-apache-
buster, 9.1.6-php8.0-apache, 9.1-php8.0-apache, 9-php8.0-apache, php8.0-apache, 9.1.6-apache-
buster, 9.1-apache-buster, 9-apache-buster, apache-buster, 9.1.6-apache, 9.1-apache,
9-apache, apache, 9.1.6, 9.1, 9, latest, 9.1.6-php8.0, 9.1-php8.0, 9-php8.0, php8.0
My question is why do they list so many variations of the version in the link (i.e. 9.1.6-php8.0-apache-buster and 9.1-php8.0-apache-buster, etc.)? I'm not sure if this is for searching and spiders (though it wouldn't need to be included in the link like they do), or if it is because each dockerfile can be modified to any of those versions? (and if so, how?). For instance, the above drupal dockerfile supports 9 - 9.1.6 and the dockerfile can be adjusted to that version. TBH, it's mainly just confusing why they do their links like that if its just for search indexing because it looks like its supporting multiple versions of something.
Today, these tags may all point to the same image. However tomorrow, 9.1.7 may be released, and when that happens, all the 9.1.6 images will remain unchanged and a new set of 9.1.7 images are built with generic tags like 9.1 and 9. Additionally when 9.2.0 is released, or php 8.1 comes out, or the next version of debian is released, any of these could be breaking changes for an app. So in your Dockerfile, you might say:
FROM ${BASE}:9.1-php8.0-apache-buster
And by doing so, you'll get the 9.1.7 when it's released, but not 9.2.0, and you won't accidentally be shifted over to nginx, or upgraded from buster to bullseye when it becomes stable. The more change your app is able to tolerate, the more generic you may be in your base image tag. The risk being one of those changes may break your app.
You can be very specific and pin to an exact base image that doesn't automatically update, but then as security vulnerabilities are patched in newer base images, your child image would remain vulnerable since it's locked to an old base image that won't receive updates.
Related
I am learning docker from linked in learning video class. Here trainer mentioned as below
Include installer in your project . Five years from now the installer
for version 0.18 of your project will not still be available. Include
it. If you depend on a piece of software to build your image, check it
into your image.
How can I check dependency into my image? My understanding is that if we build image software by giving commands like below.
FROM ubuntu:14.0
We already downloaded ubuntu software 14.0 version and created image. Why trainer is mentioning that version 14.0 is not possible to download
after 5 years down the line? Is my understanding right.
Thanks for your time in clarifying
I'm having difficulty understanding what the LinkedIn teacher is trying to explain.
For images no longer available on DockerHub there is usually many years of pre-warnings before they're removed. For example .Net Core 2.1
It's a no brainer that people (and companies) should invest to time to move away from unsecured legacy software. If an online teacher is saying pin Ubuntu 14 because you might need it in 2028, I consider that bad practice and not something a decent Engineer would ever aspire to do.
What your code is doing is asking for an Ubuntu image with the tag 14 so you can search here to see the results. 14.04 has been recently pushed and scanned for log4js (a massive security vulnerability), coming back clean which is great. On the other hand 14.04.1 was pushed 7 years ago and is clearly not maintained.
One thing most companies do is to push images to ECR/Artifactory/DockerHub/etc so you could docker pull say ubuntu:14.04 and then docker push it to your own container registry and you'll have it forever and ever amen. In this case you'd add your private registry to docker so it can discover the image or use a custom URL like my-company-images#artifactory-company.com/ubuntu:14.04
https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html
I am trying to create an app in Heroku. I have done different things to make it smaller (now it is shrunk to one third of its original version) and still its "compiled slot size" gets to 760M. So it keeps fail to push since it is larger than 500M. I am trying to figure out if there is a service that I can pay for the space and let me to push an app larger than 500M. I cannot find which service gives me such option.
I really need to solve this problem, because this is a very basic version of my app and I hope to expand it further to a commercial app.
Your slug is very large and you can try to reduce it further (especially if this is supposed to be a simple version of your application).
You can look at which dependencies you import and leave out what you don't really need: how to do it depends on your stack (for Java Maven apps you trim the POM file, Python the requirements.txt, etc..)
Check also out slugignore in case you can leave out files and assets from your project folder
A good option is to dockerize the application: the Docker images do not have the same slug restrictions.
If all the above is not successful you might need to look at a different provider (DigitalOcean has no slug restrictions but it does not have a free plan) or a change in your architecture (split the application in different components).
I was wondering, what is some good ways, to decide which TAG for Dockerfile.
For instance, I'm clear on my requirement.
I need Python 3.6
I need Alpine distribution due to its small size.
Should I pick
FROM python:3.6.6-alpine3.8
or
FROM python3.6-alpine
Even if python:3.6-alpine is an alias for python:3.6.6-alpine3.8, generally (but it's a personal preference), I tried to be as precise as possible when choosing a base image, so I would rather use python:3.6.6-alpine3.8.
It avoids misunderstanding for people reading the Dockerfile, and for people using the image, like :
Oh! Why's that library not available in the image? Maybe because of Alpine version? By the way, what's the Alpine version? I'm going to check /etc/alpine-release to see...
For Python version, it's more complicated because using 3.6.6 tag, your build can eventually fail in the future if a 3.6.7 version is released; indeed, by looking Python images versions on Docker store, only images with the latest fix version seems to be kept. But all depends if your image will need to be rebuilt, or if it's just pushed once to your own registry and then used as a base image. If regular builds are expected, in that particular case, I would maybe use 3.6-alpine3.8, because, normally, fix versions does not remove compatibility and just add small improvements/bug fixes.
In short, it does not cost anything to be precise when choosing a tag and saves a lot of explanation when the image is used : you know exactly what's in the base image you extend, just by reading the Dockerfile. But be careful if those tags have a short life expectancy.
So I upgraded to 1.4 for a project I am contributing to (in development/testing branch of course) and ran into some problems and thus we want to use Dart 1.3.6 again. However, I cannot find this.
Does anyone know where I could download it?
I have seen and starred https://code.google.com/p/dart/issues/detail?id=18323
as I was putting this question together, but of course seems like there is no more movement there just yet.
I think I pretty much ran into similar issues to what corgath described in comments on this question... looking for the right version in those "archives" where the "latest" is not really the latest anymore.
Update
There is now a nice page to select and download specific Dart versions https://www.dartlang.org/tools/download-archive/
Since a while there are also deb packages available which can be installed using
sudo apt-get install dart=1.7.0-dev.0.1.*
see https://www.dartlang.org/tools/debian.html for more details.
Original
You can download from
http://gsdview.appspot.com/dart-archive/channels/stable/release/
The list only contains the build number but each folder contains a file VERSION that contains detailed version information for this build.
dev channel releases can be found here
http://gsdview.appspot.com/dart-archive/channels/dev/release/
there are also unsigned raw builds (bleeding edge) but it is not recommended to use them.
http://gsdview.appspot.com/dart-archive/channels/be/raw/release/
Is there a place (website) where i can find information on which VM is needed (minimum/maximum) for a specific Pharo or Squeak release on a specific OS?
I don't know if that exact information is documented, but I can try to give you a brief explanation... Even Pharo and Squeak paths have diverged a lot in the last times.
Pharo Official VM is the CogVM which is a StackVM with JIT. Then it also have StackVMs for platforms where code generation is not allowed.
The official virtual machines for Pharo are listed in http://www.pharo-project.org/pharo-download, and they work for sure from Pharo 1.2 up to Pharo 2.0. You can also have a look at the complete set of built vms in the CI server https://ci.lille.inria.fr/pharo/view/Cog/.
For older releases, Pharo (1.0 and 1.1) keeps a history of one-click distribution where the vm is freezed along with the image. You can find them in here: https://gforge.inria.fr/frs/?group_id=1299
On the other side, for Squeak, the same CogVMs should work in their latest versions, otherwise you should get an interpreter VM from http://squeakvm.org/index.html.
Hope it helps a bit
As #guillepolito says, the best thing today is to take the ones from the Pharo continuous integration Jenkins server (or pick a one-click).
Squeak VMs have been fading out in my practice. I keep a number of them around but as I do use Pharo, I try to build my own version from the Jenkins source as there is a lot to be learned from using those.
It is not difficult to get them built on the main platforms and at least you know what's under.
The main problem is that Eliot Miranda keeps on doing his things in his corner instead of working on a shared source three. That's the problem of having a low truck number on that.