Docker update script / docker

Development Misc
,
1

I made an experimental docker upgrade docker, but I’m not sure whether it will really scale and work, but decided to share it, maybe others see some caveats? Or ways to make it better and scale and be configurable.

I run my environment via docker-compose, to upgrade I shutdown my production docker, mount my userdata folder in a dedicate update docker and update from that one. Than its time to recycle my main docker. And voila it (seems to) work :wink:

Custom update docker:

FROM openhab/openhab:2.2.0-snapshot-amd64-debian

RUN apt-get update && \
    apt-get install --no-install-recommends -y \
    curl && \
    rm -rf /var/lib/apt/lists/*

CMD ["gosu", "openhab", "/bin/bash"]

cd upgrade_docker
docker build -t openhab:2.2.0-update . && \
docker run -it --rm \
        -v /meru/docker-configs/openhab/userdata2:/openhab/userdata \
        openhab:2.2.0-update /bin/bash /openhab/runtime/bin/update 2.2.0-SNAPSHOT

Finally pull the new docker image recycle the docker compose container:

docker pull openhab/openhab:2.2.0-snapshot-amd64-debian
docker-compose down && docker-compose up -d

It seems to work but it has some fixed paths and other rough edges.

Please be carefull not to ruin your production enviroment with it but testing is appreciated :smiley:

2 Likes
2

Cool Stuff, it is on my agenda since along time to move openhab from a KVM VM to docker.

3

Just to be complete, the docker environment is not new only the update inside the docker, because that used be very painful.

A reference to setting up openhab in docker can be found here:

http://docs.openhab.org/installation/docker.html

It also describes an update process but that is incomplete and does not overwrite configuration / files in /userdata/etc/

4

The approval that @Benjy came up with awhile back that I haven’t had a chance to pursue yet was a bit simpler. It involved updating the entry point script to check the timestamps on the relevant files and is the version in the container is newer than the version in userdata to backup the userdata files, copy the new files over, delete cache and tmp, then start OH. That is essentially what the update does during the apt-get anyway.

That way upgrade is as simple as running the new image.

5

That sounds great! So that way it would be integrated in the standard docker image?

6

What can I do to implement this in the OH Docker Image?

7

It would require changed to the entrypoint.sh. it currently checks to see if the files exist in userdata and if not copies ten over. Add an additional check it see if the etc files in the userdata folder are older than the defaults in the image that get copied over when userdata is empty and copy the files over in that case too.

The thread where Benjy and I discussed this is here.

1 Like
8

I should probably mention that I haven’t used docker before so my suggestion was an attempt to simulate what the upgrade scripts do. It would be great to have people who actually understand docker to test my theory.

9

Would not that affect all files here?

10

I definitely think this can work if we do it conditionally and also empty the cache and tmp if the files are overwritten. Great that we have some option :+1:

11

I’m not entirely sure I understand the question. We would be copying from userdata.dist, not modifying it.

If I am reading the entrypoint.sh script correctly, it currently copies the contents of ${APPDIR}/userdata.dist to ${APPDIR}/userdata when ${APPDIR}/userdata is empty.

What we are proposing is to also check the dates on the files, or even better check the contents of version.properties.

If ${APPDIR}/userdata/etc/version.properties != ${APPDIR}/useradat.dist/etc/version.properties we know that the userdata folder being mapped into the container is for a version of OH different from the version of OH running inside the container. Therefore we should:

  • backup the files in ${APPDIR}/userdata/etc, we don’t want to completely wipe out any customizations they may have added
  • cp ${APPDIR}/userdata.dist/etc/* ${APPDIR}/userdata/etc
  • rm -rf ${APPDIR}/userdata/cache/*
  • rm -rf ${APPDIR}/userdata/tmp/*

If I’m not mistaken, those are the steps that the apt-get upgrade does when upgrading OH to a new version.

My bash programming is not all that great so I’m not entirely certain the best way to implement the above, particularly the comparison of the two version.properties files. But I think the above is a sound approach and theoretically possible. It would also make the upgrade process for the Docker image so much better.

12

@Kai How is the general update process of OH thought?

13

To clarify: The current upgrade process for any distribution should be as follows:

  1. Stop openHAB2
  2. Completely remove and replace openHAB runtime folder with the new version.
  3. There are a few system files in userdata/etc that must be replaced with a new version at each upgrade. I listed them in the script in the post linked above by @rlkoshak . Everything else in userdata and the remaining files in userdata/etc is kept the same.
  4. The conf folder is untouched.
  5. Empty the contents of userdata/cache and userdata/tmp.
  6. Start openHAB2

The above is essentially what runtime/bin/update does.

1 Like
14

  1. This will already be the case because entrypoint.sh runs before OH starts in the container

  2. This will also already have been done as the image the new container is based on will already have the new OH verion installed.

  3. This is what entrypoint.sh should copy from userdata.dist when version.properties is different. One could probably parse out the build number and just compare those to determine if we need to copy over those etc files you listed.

  4. Agreed and the approach above leaves conf untouched.

  5. That will be the last thing entrypoint.sh does before starting OH, but only in the case where it already had to update the userdata/etc files. I don’t think we want to have a blanket clearing of cache and tmp on every restart of the container.

The only addition I made was to make a backup copy of the files before replacing them.

But one question I have is what would be more future proof, to only copy that minimal set of files to userdata/etc or to copy the whole set of files. If we can come up with a scheme that is flexible and eliminates the need to make changes to entrypoint.sh everytime there is an update to the content or format of any of the userdata/etc files the better,

15

@Kai What do you think about?

16

About what in details? Could you summarize it in a short question for me (as I have no clue about docker specific stuff that you are discussing…)?
FTR, the major strategy regarding the further evolution of the upgrade process is supposed to be discussed in https://github.com/openhab/openhab-distro/issues/501.

17

@Kai My question was: What is more future-proof for all (platforms and distributions), regarding the userdata files?

18

For completeness, PR has been started here:

19

Well, imho the most future-proof solution is to have a single place where we maintain the logic that is required for upgrades…

20

Agreed, but just to make sure, the current situation is this.

  • The best solution would be to move all user-configurable files to $OPENHAB_CONF so that $OPENHAB_USERDATA is purely updated by the process.
  • The above is not easy to achieve with Karaf so instead we have a list of files in $OPENHAB_USERDATA/etc that must be updated each upgrade. For anything else (like the change in logging process in 2.2.0) we want to define a set of upgrade processes (MOVE,DELETE,COPY e.t.c.).

Therefore, the two things that the distribution would need to contain are:

  1. A CSV type list of commands to complete the upgrade
  2. A list of files in $OPENHAB_USERDATA/etc that must be deleted and replaced with the latest copy

It’s up to the package/platform maintainer to decide how to use the above two files in their own logic for updating.

1 Like