After accidental run, I can't get nextcloud's database and image in sync.
My database is somehow updated to the latest version, but the image (apps) are not.
In my config.php the version is: 'version' => '20.0.5.2'
My version.php shows: $OC_Version = array(22,1,1,2);
If I spin up docker image version 20.0.12, the image keeps restarting with this error:
Can't start Nextcloud because the version of the data (22.1.1.2) is higher than the docker image version (20.0.12.1) and downgrading is not supported. Are you sure you have pulled the newest image version?
But If I start the latest (the same version of the "data") v22.1.1.2, I can't finish the update because:
Updates between multiple major versions and downgrades are unsupported. Can't start Nextcloud because the version of the datais higher than the docker image version and downgrading is not supported.
So I am kind of stuck! I can't run previous the version because the database reports it is updated, and I can't update to the last version, because it is not supported.
What should I do?
I read I have to update 'gradually' but the database reports it's already the latest version.
Just in case somebody is still looking for answer, you need to change your version.php file back to the version matching your last working configuration (in this case probably to 20.0.5.2). Definitely use backup of this file if you have it.
If you have no backup, you can make it yourself as described here: https://help.nextcloud.com/t/skipped-major-version-21-23-did-not-run-the-updater-yet/139638/2?u=vset
Related
We have an ASP.NET Core Docker image built via the default FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base in the Dockerfile.
We have a weekly build. Our vulnerability scan raises a different issue each build for low-level Debian libraries.
E.g. Week1: issue about libraryA v1. It is recommending us to update libraryA to v2.
But the following week, when we build a new Docker image, ASPNET automatically comes with v2 of libraryA. We didn't even have to do something about libraryA. But then, new vulnerabilities are reported, which will then be automatically fixed in the coming weeks.
Is there a way to tell ASP to use a specific OS version?
From the ASPNET dockerhub,
https://hub.docker.com/_/microsoft-dotnet-aspnet/
These are the tags for Debian11:
6.0.13-bullseye-slim-amd64, 6.0-bullseye-slim-amd64, 6.0.13-bullseye-slim, 6.0-bullseye-slim, 6.0.13, 6.0
Our build last November was using 6.0.11 by checking the docker history of the image.
It reported some issue about krb5/libgssapi-krb5-2, recommending it to upgrade to version 1.18.3-6+deb11u3.
Our docker image last November was only using deb11u2 when I docker-exec'ed into it.
Today (January), if I try the following FROM to force the specific ASPNET version, the library is automatically updated to deb11u3 out of the box.
• FROM mcr.microsoft.com/dotnet/aspnet:6.0.11 AS base
• FROM mcr.microsoft.com/dotnet/aspnet:6.0.11-bullseye-slim-amd64 AS base
I am thinking of baselining a specific ASPNET or Debian version, and I will just manually address the vulnerability reports by using apt-get of those libraries. But from my testing above, it seems like Microsoft automatically updates the underlying OS even if I specify a specific version in the Dockerfile's FROM.
Any clue how to tell ASPNET to use a specific OS version? (Sorry Docker newbie here)
The aspnet Dockerfiles aren't based on pinned versions of their dependencies, so even if you pin the aspnet version you want by using 6.0.13-bullseye-slim-amd64, if Microsoft rebuild it and re-publish it, some of the underlying libraries might have been updated.
To completely pin what version of the image you want, you can use the digest in your FROM statements instead of a tag. That way, you won't get any updates at all and will always point to the exact version of the image you want.
You use it like this
FROM mcr.microsoft.com/dotnet/aspnet#sha256:5cf4aaa3fceb9bca683d56213873c0e418133a1ed36886a629bca266fb12e41b
You can find the digest by running docker inspect image <image>. The digest is in the 'RepoDigests' field. The digest is also printed when you do docker pull.
You should then add a comment in the Dockerfile about what tag the digest refers to, since that's not obvious anymore.
Let me add that this might not be a good idea to do. You're denying yourself security updates that could fix important vulnerabilities. It might be worth looking into how you can have a smooth workflow and also get these updates at the same time.
I was told it's better not to use latest in Docker File, but how can I find alternatives?
According to: https://ubuntu.com/download/desktop the latest version of ubuntu is Ubuntu 22.04.1 LTS but when I go to: https://hub.docker.com/_/ubuntu/tags I see strange tags like: bionic what is that?
and 22.10 this is a future version? how is that possible?
and while I could fine 22.04 I could not find 22.04.1
There are many problems involving the usage of latest tag on a docker image. The application is constantly changing and with it its architecture as well. While pulling an image with the latest tag, you use these changes as well. This may be good in a personal project sometimes but in a large scale application, you dont want your application to change drastically. Example:
While working on a dockerized application, we incorporated db connector to session storage redis db, the connector connected to redis at the start of the application and if it was unsuccessful, the application would not start. Every update/change on the host machine with running application meant deploying redis as well as we were using the latest tag.
22.04 Ubuntu is the latest LTS build, but there also is experimental 22.10 (ref. Ubuntu 22.10
As I move to containers, I am realizing that the container concept ties the OS and the Application into the same deployment system.
Background
docker pull mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim
This command pulls the container image setup by Microsoft for the .NET Core Runtime. That container image depends on the mcr.microsoft.com/dotnet/core/runtime-deps:3.1-buster-slim container image. And that runtime-deps container image is built from the debian:buster-slim image.
The debian:buster-slim image currently targets version 10.2 of Linux Debian. But when 10.3 is released it will target 10.3. (And I assume it targeted 10.1 when it was the current release.)
Question
When the buster-slim tag of debian gets updated to target 10.3, do all downloads of mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim get updated to start using 10.3?
Or is mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim somehow locked in at 10.2?
I am worried about something like this happening:
I make a container that depends on mcr.microsoft.com/dotnet/core/runtime:3.1.1-buster-slim and release it to production (which runs Debian 10.2)
Debian releases 10.3 of their OS and update the buster-slim tag to point to 10.3.
I do a very minor change to my container (from step 1), rebuild the container image and deploy it. But because of how docker works, my minor change also includes an unintended OS upgrade to Debian 10.3.
I expect something like this when using the tag latest, but not when I am using a specific tag.
So this can be summed up with this question:
Am I going to get dependency upgrades for a tag, even if I keep using the exact same tag?
Yes, potentially. Nothing in Docker prevents authors from uploading a new image to the same tag multiple times, even for the specific tags like you're talking about here.
I'm currently using Gitlab using Docker. The container is using the latest image for Gitlab, but the admin area shows me a different version. How can I use the latest one ? I don't understand why Gitlab shows me a different version of what I'm using. I tried gitlab-ctl upgrade command, with no effect.
Docker shows me the correct (latest) image
Administration shows me 11.1.4 (so, I can't benefit 11.4.0 features)
Am I doing thing wrong ? When updating, I just change the image version. Everything works well since months, but now...
So ! I solved my problem. I've mounted a volume on /opt/gitlab, and it seems the upgrade doesn't working when the folder already exists. Just don't mount a volume on this folder.
https://docs.gitlab.com/omnibus/docker/#where-is-the-data-stored does not show at any time this folder should be mounted.
Currently learning about Docker and I was wondering why we increment the version in Docker-Compose.
There are Three docker versions: 1, 2, and 3. Why do we have only 3 versions? ... Does version 3 give you more options?
Is it necessary to upgrade the Docker Compose version?
You are referring to the version of the file format of docker-compose.It has changed through time to add more options, but when doing so they also changed the way some of the functionality was declared, when that happens they change the major version.
The older versions are maintained o that backwards-compatibility to docker-compose files people were already using keep working with newer versions of docker and docker-compose.
If you are starting to learn, or starting a new project, the best practice is to use the latest version available.
In the documentation page you have more information about the file format of docker-compose and what's available in each version (3.7 as the writing of this comment).
Those are not versions of the docker itself. Those are versions of the configuration file format.
Each version defines which options you can use in the docker-compose.yml file. For example, see this: https://docs.docker.com/compose/compose-file/compose-versioning/