docker images of most (historical) bitcoin core versions back to v0.2.0 in 2009

[mocacinno]

Suse released sles 15 SP7 technology preview images a couple days ago. These images are released for testing compatibility with new service packs and for POC's.

In the meantime, i created new branches (ending in _SP7) for every bitcoin core version in the github repo, and i have succesfully built each version on sles 15 SP7. The images were only uploaded into github's docker repo: https://github.com/mocacinno/bitcoin_core_docker/pkgs/container/mocacinno%2Fbitcoin_core_docker/versions?filters%5Bversion_type%5D=tagged

Everything builds, but nothing was tested... If you want to help out, feel free to pull some _SP7 images and try if you can run them. If not, let me know (or create a fork, fix the issue and create a pull request).

Only use _SP7 images for testing, do not use them in production. The _SP7 branches will be merged into their respective branches once SP7 is actually maintained!!! _SP7 branches will not be added to the documentation either, these branches will seize to exist once SP7 is actually released.

[mocacinno]

v29.0 was released... At least, the v29.0 tag was created on github, so i released it on my repo...

Since the last "official" announcement is still talking about v29.0  being @ rc3, i have not tagged v29.0 as "latest". If you implemented your container infrastructure to use the latest version, you'll still pull v28.1.
I would not recommand using v29.0 in production for the time being, just wait untill it's released officially and i've re-built the images (or you can rebuild them yourself on your own infrastructure if you want).

This being said, v29.0 changed it's build process, at the beginning it looked like a difficult task, but building v29.0 is actually easyer when it comes to dependencies than the previous versions... I no longer build prereqs like boost or BerkeleyDB manually, building all those prereqs is now one very simple extra step in the cmake build process.

Documentation is also updated.

As always: if you see something wrong, fork, edit and make a pull request (or raise an issue on github or in this thread)

[mocacinno]

update:

• a repo used for older v0.2.x versions no longer exists, but the necessary packages were moved to other repo's, i modified all impacted Dockerfiles, everything builds again
• i rebuilt all images with the latest suse BCI, so the container images have the latest patches
• i tagged v29.0 as latest, since it seems stable
• i modified the documentation using nice badges, so in the future you can look at the documentation to find of when a certain version was last built, wether the build was succesfull and how big the image is... For example: v29.0 (latest) documentation
• eventough i made dockerfiles for sles 15 sp7, it's very likely the branches will never be merged. Suse just released sles 16 BCI's, so i guess i'll probably jump to sles 16 instead of 15 sp7 (16 will have much longer support)

[NotATether]

update:

• a repo used for older v0.2.x versions no longer exists, but the necessary packages were moved to other repo's, i modified all impacted Dockerfiles, everything builds again

Wouldn't it make more sense for you to simply fork the repositories to your own github account instead of pointing it to someone else's?

Github has seemingly unlimited file storage, and short of a DMCA takedown, the files aren't going anywhere.[/list]

[mocacinno]

update:

• a repo used for older v0.2.x versions no longer exists, but the necessary packages were moved to other repo's, i modified all impacted Dockerfiles, everything builds again

Wouldn't it make more sense for you to simply fork the repositories to your own github account instead of pointing it to someone else's?

Github has seemingly unlimited file storage, and short of a DMCA takedown, the files aren't going anywhere.[/list]

Those are package repo's (not github repo's), some of them are Gb's of (binary) rpm packages, sometimes even providing regular patches. I'm not sure github would approve if i cloned those into a github repo

For github repo's, you do have a valid point, i should probably fork those, so i'm not longer depending on repo's that might be removed in the future. I'll put that one on my to-do list.

[mocacinno]

v29.1 was released just a couple moments ago. Documentation will be updated in a couple of hours.

The tag "latest" was assigned to v29.1, so anybody running the latest version will automatically update to v29.1

In august, i rebuilt all images, so pull the new images if you've been running for a while. Newer images contain a smaller attack vector since os patches are applied in newer version.

[mocacinno]

i've just released v30.0 docker container:

Code:

docker pull mocacinno/btc_core:v30.0
#or
docker pull mocacinno/btc_core:latest

If you want to build it yourself, here's the Dockerfile: https://github.com/mocacinno/bitcoin_core_docker/tree/v30.0

The documentation site isn't updated (yet), i'll try to update it this afternoon (or tomorrow)... Ugh, i don't like writing documentation  

The last couple of weeks, i've included an sbom and provenance with my docker images, you can find them on ghcr.io (so they're not available on dockerhub yet), i've also switched to using a unprivileged user inside the container instead of using root... I had not yet communicated these changes.

[mocacinno]

i'm slowly thinking about migrating from sles 15 sp7 to sles 16.
Sles 15 SP7 containers are no longer supported after 31 Jul 2031, sles 16 will be supported WAAAAY longer... This basically gives me >5 years to migrate

Don't worry, the sles15 sp7 containers will be refreshed every couple of months, the images will be patched regularly for new vulnerability's untill the time the sles16 conversion is completed.

In the process of migrating to sles 16, i want to clean up my code. I'm finished with v2.0. Here are the differences:
https://github.com/mocacinno/bitcoin_core_docker/compare/v2.0...v2.0_SLES16

Most notably:

• new images use sles 16 (that was basically the point)
• more labels, make sure people have sufficient metadata when analyzing the images
• all sources now go into the /src directory
• more comments in the Dockerfile, let other helpers know what we're doing exactly
• everything downloaded from the internet now is checksummed to avoid supply chain attacks (suse repos are signed and trusted)
• multi stage build, safer and waaaay smaller (~90% smaller). Versions >v0.2.7 were already multi stage, now pre v0.2.7 will also be
• now running under unprivileged user (this is also implemented in the sles15 sp7 builds)
• no longer hardcoded password in bitcoin.conf. Moved logic to init.sh. In case the entrypoint.sh is used, init.sh will be called automatically. If you run the container interactively, you'll have to run it manually. Init.sh creates a couple of things, amongst others a random password
• Persistent blockchain data volume instead of mapping a local directory... Safer in case people mess around with the container and forget to map a local directory
• Potential cmd stub in Dockerfile for future flags
• Short TL;DR; Readme.md with the basic way(s) to start the container... Nothing more, nothing less

In case somebody is interested in helping me out: don't hesistate to fork, modify and create pull request. I want to use the v2.0_SLES16 branch as a "template", the naming convention of the branch is v<x>.<x>_SLES16, the Dockerfile template is the template i created for v2.0_SLES16.
It's a huge job, without help it'll probably take me several months... Helpers will get credit on mocacinno.com
There are a couple of "freebies": v2.1-v2.9 already have "dirty" code that actually builds for sles 16 (i already did the conversion), so those versions are basically just converting the dirty code to clean code without worrying about failing builds

In case anybody is interested in helping: shoot me a pm, so we're not both working on the same version

version	compiler	status
v0.2.0	mocacinno	done
v0.2.1	mocacinno	done
v0.2.2	mocacinno	done
v0.2.3	mocacinno	done
v0.2.4	mocacinno	done
v0.2.5	mocacinno	done
v0.2.6	mocacinno	done
v0.2.7	mocacinno	done
v0.2.7-gui	mocacinno	done
v0.2.8	mocacinno	broken
v0.2.9	mocacinno	reserved
v0.2.10		todo
v0.2.11		todo
v0.2.12		todo
v0.2.13		todo
v0.3.0		todo
v0.3.1		todo
v0.3.2		todo
v0.3.3		todo
v0.3.4		todo
v0.3.5		todo
v0.3.6		todo
v0.3.7		todo
v0.3.8		todo
v0.3.9		todo
v0.3.10		todo
v0.3.11		todo
v0.3.12		todo
v0.3.13		todo
v0.3.14		todo
v0.3.15		todo
v0.3.16		todo
v0.3.17		todo
v0.3.18		todo
v0.3.19		todo
v0.3.20		todo
v0.3.21		todo
v0.3.22		todo
v0.3.23		todo
v0.3.24		todo
v0.4.0		todo
v0.5.0		todo
v0.5.1		todo
v0.5.2		todo
v0.5.3		todo
v0.6.0		todo
v0.6.1		todo
v0.6.2		todo
v0.6.3		todo
v0.7.0		todo
v0.7.1		todo
v0.7.2		todo
v0.8.0		todo
v0.8.1		todo
v0.8.2		todo
v0.8.3		todo
v0.8.4		todo
v0.8.5		todo
v0.8.6		todo
v0.9.0		todo
v0.9.1		todo
v0.9.2		todo
v0.9.3		todo
v0.9.4		todo
v0.9.5		todo
v0.10.0		todo
v0.10.1		todo
v0.10.2		todo
v0.10.3		todo
v0.10.4		todo
v0.10.5		todo
v0.11.0		todo
v0.11.1		todo
v0.11.2		todo
v0.11.3		todo
v0.12.0		todo
v0.12.1		todo
v0.13.0		todo
v0.13.1		todo
v0.13.2		todo
v0.14.0		todo
v0.14.1		todo
v0.14.2		todo
v0.14.3		todo
v0.15.0		todo
v0.15.1		todo
v0.15.2		todo
v0.16.0		todo
v0.16.1		todo
v0.16.2		todo
v0.16.3		todo
v0.17.0		todo
v0.17.1		todo
v0.17.2		todo
v0.18.0		todo
v0.18.1		todo
v0.19.0		todo
v0.19.1		todo
v0.19.2		todo
v0.20.0		todo
v0.20.1		todo
v0.20.2		todo
v0.21.0		todo
v0.21.1		todo
v0.21.2		todo
v22.0		todo
v22.1		todo
v23.0		todo
v23.1		todo
v23.2		todo
v24.0		todo
v24.1		todo
v24.2		todo
v25.0		todo
v25.1		todo
v25.2		todo
v26.0		todo
v26.1		todo
v27.0		todo
v27.1		todo
v28.0		todo
v28.1		todo
v29.0		todo
v29.1		todo
v29.2		todo
v30.0		todo

[mocacinno]

v30.1 was released a couple of minutes ago (well, actually, it was released 3 days ago, but i released the docker image a couple of minutes ago )...

Code:

docker pull ghcr.io/mocacinno/mocacinno/bitcoin_core_docker:v30.1

On dockerhub, the latest tag was moved from v30.0 to v30.1, so anybody using the latest tag instead of a specific version inside of their compose files will switch automatically the next time the container is restarted.

The documentation will be updated later today (or later this week, depending on my workload irl)

I'm currently in the process of doing a monthly rebuild of all other 15 SP7 containers (as promised), to keep them up to date with the latest patches . SLES16 containers are currently undocumented, they do not get regular rebuilds and could potentially have CVE's... If you want to use these images, i suggest you manually rebuild them before using them!

[mocacinno]

v30.0 and v30.1 contained a big bug, eventough the binary's were pulled from bitcoin's github repo, i chose to let the images stay on my repo for the sake of completeness.
As soon as i was made aware of the situation, i did write a clear warning on my documentation page.

A very short while ago, v30.2 was released. It's currently building and it'll be available on ghcr.io once the workflow completes: https://github.com/mocacinno/bitcoin_core_docker/actions/runs/20855632495

Since i'm getting ready to leave the office for the weekend, i probably won't have time to move the image to dockerhub, or to tag v30.2 with the "latest" tag. I'll probably do this (and update the documentation) on monday morning.

I would advise anybody using my images to manually get the image from ghcr.io once it finishes building, the bug is quite an edge case, but it's still better to be safe than sorry!

[NotATether]

v30.0 and v30.1 contained a big bug, eventough the binary's were pulled from bitcoin's github repo, i chose to let the images stay on my repo for the sake of completeness.
As soon as i was made aware of the situation, i did write a clear warning on my documentation page.

I think this is the correct move, since these container images are mostly used for archival purposes, and most are not used in production.

Since i'm getting ready to leave the office for the weekend, i probably won't have time to move the image to dockerhub, or to tag v30.2 with the "latest" tag. I'll probably do this (and update the documentation) on monday morning.

In this particular case I think most people are pulling specific versions of the image rather than using the latest tag, since it's not synchronized as quickly as e.g. Bitcoin Core website (which is not a container registry but is just here as an example). But I could obviously be wrong as I don't have any data on this.