illogical docker installation method #585
Comments
|
Oh, I so agree!!! All the IOTstack install methods have always been a bit of a mess. I gave up trying to persuade an approach of a single script that was not either embedded in the menu or ever called by it, and which simply did the job of installing (not the double-duty of updating). And all that daft version checking - gives me the heebies. This is, pretty much, why I went my own way with PiBuilder, particularly the 04_setup.sh script. Recently, the goal-posts moved again. Now, the docker convenience script also installs The good thing, now, is that routine As it should always have been! |
|
Just to call it out - the last element on this line of your output: |
Yup, this brings Compose v2, while the I'm thinking, for IOTstack, the 'correct' (=simplest that just works) thing to do, is to just use Debian's bundled docker and docker-compose packages, and not mess around with get.docker.com. At least if the Both packages do have support for the no-hypen |
|
I think I'd disagree that "simplest" equals installing docker and docker-compose-plugin from the convenience script, followed by installing docker-compose from apt which promptly uninstalls docker and installs a different version. I'd see "simpler" as just running the convenience script - full stop. Aside from futzing with docker, the problem with the apt version of For a good 18 months the interim solution (whenever one of those bugs/limitations showed up) was to explain how to remove the obsolete version of docker-compose in favour of the python version (1.29.2). To begin with that (a) didn't futz with docker and (b) resolved the corner cases - at least, all the ones I knew about. More recently, zapping the apt-installed docker-compose left you with a broken docker so the only solution was to nuke everything, run the convenience script to get docker back, then run pip to get docker-compose. The modern version (written in go) started as a port of 1.29.2. It's evolving quite rapidly solving plenty of bugs and issues as it goes along (and, no doubt, introducing new ones - that being the nature of programming). For a time, PiBuilder always pulled down the latest and greatest docker-compose from the releases page. While that never caused any problems for me, and while nobody ever opened an issue on the PiBuilder repo complaining that a "bleeding edge" version had broken something, I was conscious that it was somewhat heroic to assume the latest and greatest would always be 100% reliable. It also depended on me updating the scripts to hard-code the version number because there was (and is) no concept like "latest". I really didn't want to be in that kind of loop because me bumping a version number kinda implied I'd done some basic testing. I did but I it would hardly qualify as "comprehensive". Right now, the "release" version is 2.6.1 but what you get from installing from the convenience script as There are quite a few advantages to the modern version. It uses BuildKit and is a heckofalot faster if you're developing your own containers. It also does away with the doubling-up you get with base images plus local images if Dockerfiles are involved, and that reduces confusion among people who see "unused" in Portainer and worry about it. Pruning seems to be more efficient too, particularly if you're iterating doing test builds of containers. The main reason I'd like to see IOTstack just use the convenience script - full stop - is because of the mess you get if you do anything else. It's people who have a perfectly functioning system, hit a limitation caused by using an obsolete version, get told how to fix that (nuke and reinstall), get the heebies and then come back and ask the perfectly valid question about why the heck IOTstack didn't do it "right" in the first place? Other than shrugging my shoulders, I have no answer to that. I'm not here to persuade you (or anyone) of anything. Whatever floats your boat. If you think it's best to continue with the current scheme, go for it. My view is that it creates a platform that is frozen in time. Whether that's good or bad depends on each person's needs and viewpoint. PiBuilder is always there for anyone who wants to opt-in to regular updates from the folks at Docker. |
Needs the script plus symlink to docker-compose. I was suggesting option 3, but now that you mentioned pip, did some some testing and I'll go with option 2. When I have the installation scripts cleaned up, let's see about upgrading to option 1 with compose v2. One step at a time. Options being:
Can't find an issue describing this. Wasn't this a pretty complex issue where a) cgroup rules require a certain version header in the compose file and b) the required compose file version requires a certain docker-engine and docker-compose versions? This is just a faint memory and might be completely off-the-mark. From https://docs.docker.com/compose/compose-file/compose-file-v3/
Hence only options 1 and 2 support the latest compose file version. |
|
The downside of option 2 being both compose versions (v1 and v2) are installed: $ docker compose version
Docker Compose version v2.6.0
$ docker-compose -v
docker-compose version 1.29.2, build unknownHopefully this won't be confusing, as only the latter form is used in the docs. |
|
I don't remember all the details either. It was just that each time "x doesn't seem to work - it's in the compose spec - what gives?" would pop up in an issue or on Discord, the solution would be 1.29.2. I think the version header is also deprecated in the spec but, at least for a time (possibly even now) some features seemed to need "a version greater than yeah" to activate. Incidentally, I'm not sure how far back you can go before We are destined to disagree on many things if you equate creating a symlink with what happens with an apt-installed compose and the problems it stores up for the future as being on the same level of complexity. Just sayin' ... The main problem I foresee with assuming/accepting 1.29.2 plus 2.x on the same system on the basis that all our doco uses the hyphenated form is that I suspect the plug-in form is going to become more common elsewhere on the Internet. People following recipes are then going to get different behaviours and, eventually, will run I'm not really sure what's bugging you about 2.x. I've been using it on all my systems (live and test) since it became a thing. There was one brief regression when the much-mentioned device cgroup rules stopped working (I actually use that for OctoPrint so I smacked into it when it happened) plus it exposed a subtle issue with volumes mappings at one point. Both of those were fixed "toot sweet" (as Terry Pratchett would say) plus I put in a PR on IOTstack to regularise all our volumes mappings as a fail-safe (just removing any trailing slashes). But, aside from those two, 2.x has Just Worked. I have zero doubts about recommending it as the tool to use. Zero. |
|
Okay, I'm convinced. Any change to docker-compose is anyway a source for possible bugs and it's safest to use what is known and working in PiBuilder. Another annoyance/problem is supporting two installation methods. Lots of semi-duplicated code and double the bug-surface and testing needs. I think choosing just one and making it as smooth and reliable is the way to go. Options in my mind:
Here options 1 and 2 are the current existing install methods. Option 3 is what I think would be good for a bit of clarity. |
|
There is a direct Docker install script: https://github.com/docker/docker-install |
|
I'll go back a few steps to set the scene. The link you have provided is something I wasn't aware of so thanks for that. What we've been using to install docker is the so-called "convenience script" which is documented here, and which boils down to:
Historically, the convenience script only installed docker and related components like docker-ce and containerd.io. It didn't install docker-compose and neither did it do anything else needed to make docker fully usable on the Raspberry Pi, such as add the current user to the docker group. In the past, you had to do that yourself. More recently, the convenience script has started including will work while the historical form: will fail. If your Pi isn't green fields and you have an older version of
Sorting out And that still doesn't get you all the scaffolding you really need for usability. Part of IOTstack's "problem" is the installation, version-checking and dependency handling has grown like topsy. It's scattered all over the place, is inconsistent, and isn't really fit for purpose. Just one example is in install.sh:
My own view of all this is that IOTstack should state its dependencies but should not install, update or check anything. The menu should just do its job of creating
My own approach to solving this problem is PiBuilder. Given media (SD/SSD) with a fresh Raspberry Pi OS image, running the PiBuilder scripts in order gets you a rock solid platform, with docker, docker compose plugin, and IOTstack installed, all dependencies satisfied, all scaffolding in place, all ready for the menu to run. My original goal was to do everything to stop the menu from trying to do anything else to the Pi, and let it concentrate on its job of building compose files. That goal took a bit of a smack around the earhole when the menu was changed to do all the Python work in a venv but I've adapted around that.
Getting agreement on the way forward is the real problem. Despite the age of this issue (June 2022), discussions are ongoing:
PiBuilder also has a bunch of problem-solving scripts like:
I always say "your Pi, your rules" so it's always up to you how you install anything. Anyway, it isn't just the convenience script. That's merely the lid on a massive can of worms. 😎 Slyke (this site's maintainer) has been pushing me to look at Ansible - essentially to replicate what PiBuilder does in Ansible playbooks. I'm looking into that now. As an aside, Andreas recommending cloning PiBuilder into |
Too muck work for a lazy people. I think we can write github actions workflow and run these tests on virtual machines. |
One of the most surprising things about SensorsIot#729 (at least to me) was how it implied that someone had actually used the `install.sh` script. I say this with the utmost respect for the original author and subsequent contributors (who did all the work while I just sat on my hands) but, after studying the existing script, I reached the conclusion that the wisest course of action was to start from scratch. There were seemed to be so many issues in the existing `install.sh` that it was difficult to know how much could be salvaged: * It creates `.new_install` in the current working directory (typically `~`) **before** cloning IOTstack. The menu, of course, expects that file to be in `~/IOTstack` so the menu thinks no installation work has been done. * It (correctly) uses the "convenience script" to install `docker` but then uses `apt` to install `docker-compose` (which is wrong). The result is the Python version of `docker-compose` being installed and, as a side effect, `docker` is unconditionally downgraded to a compatible version (which is where the problematic `+dfsg1` version suffix comes from - see SensorsIot#496). The long-term effect is that both `docker` and `docker-compose` become pinned and are never subsequently upgraded by `apt`. Another side-effect is the version of `docker-compose-plugin` installed by the convenience script becomes inaccessible. * The `usermod` commands for `bluetooth` appear twice; those for the `docker` group three times. This probably doesn't actually harm anything but it certainly doesn't lend itself to clarity of intention. * The version-checking is brute force and makes assumptions that won't always necessarily hold, such as that there are always three SEMVER components and that suffixes like `+dfsg1` won't result in a mess, like they did in similar code in the menu (again I refer to SensorsIot#496. And SensorsIot#503. And SensorsIot#585). Indeed, it's really only luck which means the `+dfsg1` doesn't appear until after `install.sh` has finished its work. What this replacement script attempts to do is: 1. Use absolute paths throughout so there is no ambiguity about where files/folders are located. Although this replacement script defaults to `~/IOTstack` the default can be overridden by prepending the correct path, as in: ``` $ IOTSTACK="$HOME/TestIOTstack" ./install.sh ``` 2. Use a **rational** method of version checking (specifically `dpkg --compare-versions`) which can actually handle the cases of one, two, three or more SEMVER fields correctly and which isn't fazed by weird suffixes. 3. Install the minimum set of dependencies needed by IOTstack. This is on the assumption that `install.sh` may be being used on either a green-fields system or an existing system. PiBuilder excels at green-fields but could prove problematic were it to be used on an already-highly-customised working system. My own view is that a clean slate plus PiBuilder produces a better outcome but there is definitely a case to be made for supporting adding IOTstack to an existing system. 4. Install `docker` and `docker-compose-plugin` correctly so both `docker-compose` (with hyphen) and `docker compose` (without hyphen) are the same binary and produce the same result. One side effect of correct installation is that both `docker` and `docker-compose-plugin` are updated by `apt`. 5. Adds the user to the required groups (once!). 6. Installs Python dependencies in a Bookworm-friendly manner. And, yes, I do realise using `--break-system-packages` is suboptimal but that's something that can be addressed by people with Python expertise (and, given no PRs have been submitted to attend to this, those people are probably a bit thin on the ground). In my view a dash of *sub-optimal* is better than not working at all on Bookworm. 7. Sets Raspberry Pi cmdline options on a per-option basis, rather than assuming the options will always appear in the same order. This replacement script is also specifically designed to be run multiple times without doing any harm. It is also designed so that it can be run safely *after* a PiBuilder run. This serves four purposes: 1. If the script is being run on an existing system where, say, an obsolete version of `docker` is installed, the script will explain how to remove `docker`, after which the script should be re-run. This basic approach of check, explain how to recover, re-try, continues until the script completes normally. 2. Ultimately, my intention is to propose another PR to remove **all** "installation" and version-checking tasks from the menu. To that end, this replacement script writes its exit status to `~/IOTstack/.new_install`. Eventually, I see the menu behaving like this: - if `.new_install` is not present or is present and contains a non-zero exit code, the menu will prompt the user to run the (replacement) `install.sh`. 3. As a guided-migration tool. Once the menu has been changed as above, the mostly likely situation a user will encounter after the subsequent pull from GitHub is the menu recommending that (the new) `install.sh` should be run. If the script finds the user's environment is obsolete (eg ancient pinned versions of `docker` or `docker-compose`) the script will guide the user through the upgrade. Rinse, repeat and eventually the script will complete normally, after which the user's system will be fully up-to-date and the menu will just get on with the job of being the menu. 4. As a general-purpose "fixup" tool. Anyone reporting problems with IOTstack which implicate anything this replacement script is designed to handle can be instructed to run `install.sh` and see what happens. This replacement script updates minimum version numbers to something more recent: * docker version 24 or later (previously 18.2.0 or later) * docker-compose version 2.20 or later (previously not checked) * Python version 3.9 or later (previously 3.6.9 or later) I have tested this script on: 1. Raspberry Pi 4B running Bullseye and Bookworm. 2. Debian on Proxmox, running Bullseye and Bookworm. 3. Multiple runs of this script on each of the above (to ensure second or subsequent runs do no harm). 4. After running PiBuilder on clean installs of all four test platforms (ie 1+2 above), also to ensure a run does no harm. 5. After running the **existing** `install.sh` on all four test platforms, to ensure any damage (eg pinned obsolete versions) is discovered and reported, and that by following the repair instructions and re-running the **new** `install.sh` ultimately gives the platform a clean bill of health. Documentation will be added to SensorsIot#737 shortly. Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com>
When testing 2022-04-04-raspios-bullseye-arm64-lite.img (using qemu):
install.sh (and scripts/install_docker.sh) installs docker and docker-compose with:
Script from get.docker.com adds a repository and installs docker-ce:
This installs:
But then when installing docker-compose the previously installed docker-ce is removed and Debian's version replaces it:
This results in:
It's useless to install the updated docker-ce just to remove it immediately!?
The text was updated successfully, but these errors were encountered: