I have been running Kiwi TCMS as a Docker container, the version running is 9.0.1. Now I have seen the latest version 10.0, so like to update it. Not sure this will not break the existing data.
So, I have taken the database and uploads files backup by following it,
https://kiwitcms.org/blog/atodorov/2018/07/30/how-to-backup-docker-volumes-for-kiwi-tcms/
But, how can I downgrade to an older version image, if the latest version does not work as expected or any problem comes? I found the docker tag concept and not sure how to apply it?
Can you confirm following will restore to an older version?
Restore the DB files and uploaded files that already taken backup.
Change the image in docker-compose file to an older one? Like my case, I could want to pull the version 9.0.1 image, so changing the image: kiwitcms/kiwi:9.0.1 works?
web:
container_name: kiwi_web
depends_on:
- db
restart: always
image: kiwitcms/kiwi:9.0.1
Or how should I tag version 9.0.1, and then restore the tagged version, in case of reverting the latest upgrade?
But, how can I downgrade to an older version image, if the latest version does not work as expected or any problem comes? I found the docker tag concept and not sure how to apply it?
The easiest way would be to destroy the instance you were not happy with, start a new one (with v9.0.1) from scratch and restore the files/DB from your backup. I am assuming you made the backup before the upgrade.
image: kiwitcms/kiwi:9.0.1 works?
In theory that would work but in practice it won't because Kiwi TCMS upstream doesn't ship version tagged container images. See https://kiwitcms.org/#subscriptions, lines Only latest releases vs. Versioned releases from kiwitcms/version.
Or how should I tag version 9.0.1
Depending on what you've already done or not done this could either be possible or not possible:
Execute docker images and if you see something like
kiwitcms/kiwi latest 9f23186803d5 8 weeks ago 736MB
kiwitcms/kiwi <no tag> <another image hash> ...
this means that latest points to v10 while the untagged image is your previous image, 9.0.1 in your case. You can then use docker tag command to tag it and make use of it inside docker-compose.yml file.
If you only see a kiwitcms/kiwi:latest image this means you have removed the previous one from your system. You don't have access to it. Your options are:
Rebuild that from source using the same git tag or
Purchase a subscription to be able to access the private kiwitcms/version repository if it is critical to restore back to the old version.
As a good practice you can follow these 2 advices:
Use the "restore-from-backup" technique or maybe "clone the docker image" so that you are upgrading and experimenting with a different Kiwi TCMS instance, not the main one that you use. If you are happy with the latest version then you can upgrade the main instance. Note here that by "clone the docker image" I mean make the running image/container files available on a different machine or possibly the same host machine but launch a secondary Kiwi TCMS instance + a secondary DB. ATM I'm not sure how exactly to do this but either docker itself or other Linux tools should be able to help here.
docker tag your local kiwitcms/kiwi images when you download/deploy/upgrade them so that you can have a reference to the version at this point in time. This will avoid losing the older image.
Extra tip: with docker tag you can also provide your own customized image names and possibly upload these images to your own docker repository for later access/backup or distributing them between multiple host systems.
Related
I'm very new to docker and docker-compose things. I have tried to use Kiwi TCMS open source project which supposed to use with Docker.
My question is can I run the projects on docker on the same server, I'm supposed to configure my development and production sites on the same server (CentOS)?
I'm following the below link to install docker and configure the kiwitcms application for the first time, I read the basics about the docker and how its working and all.
https://kiwitcms.readthedocs.io/en/latest/installing_docker.html#
I want to use PostgreSQL as my Database, but the existing latest docker image has MariaDB. So after I pulled latest version of kiwitcms from docker hub using the following command,
docker pull kiwitcms/kiwi
Should I change to "docker-compose.yml" file db image value, and save it to a local new directory,
https://raw.githubusercontent.com/kiwitcms/Kiwi/master/docker-compose.yml
[![enter image description here][1]][1]
Also there can we edit use our own DB name, user name passwords right?
then execute the following command.
docker-compose up -d
I'm very new to this model and read most of the articles related to docker, but this leads me few of these doubts, hence asking for these clarifications.
Thanks,
Karthik.
The web app and the DB server are 2 different images (aka 2 different servers). For example how we use Postgres in testing see:
https://github.com/kiwitcms/Kiwi/blob/master/docker-compose.postgres
I've been studying "Kubernetes Up and Running" by Hightower et al (first edition) Chapter 13 where they discussed creating a Reliable MySQL Singleton (Since I just discovered that there is a second edition, I guess I'll be buying it soon).
Using their MySQL reliable singleton example as a model, I've been looking for some sample YAML files to make a similar deployment with Microsoft SQL Server (Express) on Docker Desktop for Kubernetes.
Apparently I need YAML files to deploy
Persistent Volume
Volume claim (should this be NFS?)
SQL Server (Express edition) replica set (in spite of the fact that this is just a singleton).
I've tried this example but I'm confused because it does not contain a persistent volume & claim and it does not work. I get the error
Error: unable to recognize "sqlserver.yml": no matches for kind "Deployment" in version "apps/v1beta1"
Can someone please point me to some sample YAML files that are not Azure specific that will work on Docker Desktop Kubernetes for Windows 10? After debugging my application, I'll want to deploy this to Azure (AKS).
Wed Jul 15 2020 Update
I left out the "-n namespace" for the helm install command (possibly because I'm using Helm and you are using helm v2?).
That install command still did not work. Then I did a
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
Now this command works:
helm install todo-app-database stable/mssql-linux
Progress!
When I do a "k get pods" I see that my todo-app-mssql-linux database is in the pending state. So I did a
kubectl get events
and I see
Warning FailedScheduling pod/todo-app-database-mssql-linux-8668d9b88c-lsh5l 0/1 nodes are available: 1 Insufficient memory.
I've been google searching for "Kubernetes insufficient memory" and can find no match.
I suspect this is a problem specific to "Docker Desktop Kubernetes".
When I look at the output for
helm -n ns-todolistdemo template todo-app-database stable/mssql-linux
I see the deployment is asking for 2Gi. (Interesting: when I use the template command, the "-n ns-todolistdemo" does not cause an error like it does with the install command).
So I do
kubectl describe deployment todo-app-database-mssql-linux >todo-app-database-mssql-linux.yaml
I edit the yaml file to change 2Gi to 1Gi.
kubectl apply -f todo-app-database-mssql-linux.yaml
I get this error:
error: error parsing todo-app-database-mssql-linux.yaml: error converting YAML to JSON: yaml: line 9: mapping values are not allowed in this context
Hmm... that did not work. I try delete:
kubectl delete deployment todo-app-database-mssql-linux
kubectl create -f todo-app-database-mssql-linux.yaml
I get this error:
error: error validating "todo-app-database-mssql-linux.yaml": error validating data: invalid object to validate; if you choose to ignore these errors, turn validation off with --validate=false
So I try apply:
kubectl apply -f todo-app-database-mssql-linux.yaml
Same error!
Shucks.... Is there a way to adjust the memory allocation for Docker Desktop?
Thank you
Siegfried
Short answer
https://github.com/helm/charts/blob/master/stable/mssql-linux/templates/pvc-master.yaml
Detailed Answer
Docker For Desktop comes already with a default StorageClass :
This storage class is responsible for auto-provisioning of PV whenever you create a PVC.
If you have a YAML definition of PVC (persistent volume claim), you just need to keep storageClass empty, so it will use the default.
k get storageclass
NAME PROVISIONER AGE
hostpath (default) docker.io/hostpath 11d
This is fair enough as Docker-For-Desktop Cluster is a one node cluster. So if your DB crashes and the cluster opens it again , it will not move to another node, because simply, you have a single node :)
Now should write the YAML of PVC from scratch ?
No , you don't need. Because Helm should be your best friend.
( I explained below Why you have to use Helm even without deep learning curve)
Fortunately, the community provides a chart called stable/mssql-linux..
Let's run it together :
helm -n <your-namespace> install todo-app-database stable/mssql-linux
# helm -n <namespace> install <release-name> <chart-name-from-community>
If you want to check the YAML (namely PVC) that Helm computed, you can run template instead of install
helm -n <your-namespace> template todo-app-database stable/mssql-linux
Why I give you the answer with Helm ?
Writing YAML from scratch lets reinventing the wheel while others do it.
The most efficient way is to reuse what community prepare for you.
However, you may ask: How can i reuse what others doing ?
That's why Helm comes.
Helm comes to be your installer of any application on top of kubernetes regardless how much YAML does your app require.
Install it now and hit the ground choco install kubernetes-helm
I came in to the office yesterday morning to find that my Capybara tests couldn't interact with Chrome. I'm seeing
Selenium::WebDriver::Error::UnknownError: unknown error: unable to discover open pages
Googling around revealed that this was likely caused by an out-of-date chromedriver or selenium-webdriver, which sounded very plausible, since neither had been updated in a long time (I think chromedriver was at 2.2 and selenium-webdriver was at 2.35.1), and since Chrome auto-updated to 32.0.1700.77 on January 14, that seemed like good solid evidence to me.
So I've updated selenium-webdriver to 2.39.0. Figuring out what version of chromedriver I had been using actually turned out to be more difficult. I had a version of chromedriver sitting in my Downloads directory that I thought my code was referring to, but I couldn't find my Downloads directory in the PATH (I'm using OS X by the way). I tried replacing this file with version 2.8 from here, but it had no effect. I became skeptical that the version in my Downloads directory was the version that was being used in the first place, so I used brew to install it. brew info chromedriver now yields:
chromedriver: stable 2.8
http://code.google.com/p/chromedriver/
/usr/local/Cellar/chromedriver/2.8 (2 files, 21M) *
Built from source
From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/chromedriver.rb
Looks good. My PATH contains /usr/local/bin, which has a chromedriver link to the location brew installed to. As far as I understand it, this should allow my automation to detect and launch the chromedriver.
Unfortunately, my issue is still unresolved. I remain unable to discover pages. Can anyone confirm that I've done what one normally does to set up the chromedriver?
Side Question: After downloading chromedriver 2.8 directly and also installing it with brew, I tried launching both the downloaded version and the brew version separately to confirm that either version could launch successfully. I'm certain they are both in fact version 2.8, but when I launch either one the console says:
Starting ChromeDriver (v2.2) on port 9515
Is that normal? I certainly wasn't expecting it to say v2.2, but there are no other versions apart from 2.8 installed by brew (so I doubt brew is accidentally using the older version), and when I run the file I downloaded directly, I'm quite sure it's version 2.8 from the Chromedriver website. Is this an oversight on their part, or does v2.2 refer to something else, unlikely though that may seem?
It would be tricky to verify the chrome driver version frequently when you download it with homebrew. I would suggest downloading the driver and maintaining it in a folder mapped in your PATH.
So that maintaining or identifying the driver version will be easy with the below steps:
Go to the folder where you have chromeDriver
Open command prompt pointing the folder
run: chromeDriver -v
ChromeDriver is at version 2.16 now. I would recommend manually updating your driver instead of updating with whatever older version that homebrew wants to update you to.
You can use command line: pip freeze to list down all packages you have installed with their version.
Or you also can use pip show <package name> to check the details of the package, which also includes package version.
Click here
chrome driver version
for checking your chrome driver version.
Now it's time to check the latest release version. So click here latest release version
Compare between;
I'm using Collabnate Subversion Edge.
I'm getting below error when trying to access URL http://localhost:3343/csvn.
Collbnate is set up on Windows Server 2008.
HTTP ERROR: 503
Problem accessing /csvn/. Reason:
Service Unavailable
Powered by Jetty://
How to solve it?
I spent two days fighting with the same problem. It turned out that CollabNet Subversion Edge 4.0.11 does not support Java 8.
The following procedure helped me make CN Subverion Edge 4.0.11 work again on Windows 7:
1) Uninstall CollabNet Subversion
2) Uninstall Java 8 (I had Java 7 and 6 side by side, so after uninstalling the 8, 7 picked up after I added it to PATH variable. It is important to add it at the very beginning of the path, otherwise Windows\System32\java.exe will be taken, which was not good for me also)
3) Install CollabNet Subverion (the important thing is to uncheck the "Run CollabNet ..." check box in the final screen. It looks like the installer is still creating files at the end and only after I have clicked OK in the final screen the needed configuration files have been created in data/conf folder.
4) Make sure that data/conf/httpd.conf file is created. If it is there, got to services (services.msc) and start server manually
Now launch the browser and navigate to localhost:3343/csvn.
Good luck.
1) Install Java 7
2) In file \csvn\svcwrapper\conf\wrapper.conf change from #wrapper.java.command.maxVersion=1.6 to wrapper.java.command.maxVersion=1.7
3) Run \csvn\svcwrapper\bat\runConsole.bat
Good luck.
Check in c:/csvn/data/logs for a log that starts with "console". Then find the error(s) and check what is wrong.
Did you try restarting the service ?
I had the same issue, CollabNet Subversion Edge version 4.0.4. In my case the problem was updating the JAVA_HOME from JDK 1.6 to JDK 1.7.
I finally resolved it changing the file:
C:\PROGRA~1\csvn\svcwrapper\conf\wrapper.conf
I changed the value of the property: wrapper.java.command:java
wrapper.java.command=C:/PROGRA~1/Java/jdk1.6.0_45/bin/java
So the csvn now runs with 1.6 as before. And it works again as a service automatically.
Good luck!!
There's an alternative issue that results in the same error: The database may get corrupted. This is what just happened to me. The above answers where not working in this case. As Subversion Edge 5.0.1 comes bundled with jre8, it would be rather strange if it weren't able to run against it.
To solve the problem, I had to patch the database (luckily, the user database c:\csvn\data\csvn-production-hsqldb.script is a plain text sql file).
Backup files in c:\csvn\data
Delete csvn-production-hsqldb.script and start the service (should come up now)
Exit the service
Save the file which is automatically recreated now
Compare your old file and the new working one
Replace every line starting with INSERT INTO QRTZ in your database with the corresponding lines from the working copy
Copy the new files to the proper place
Start the service
Hope it worked
I had this problem too. Upgrade to SubversionEdge 5.1.4 solved the issue.
We encounter this problem with CollabNet Subversion Edge 3.3.1 every time we patch our JDK 6 install (e.g. IAVM update). We need to install JDK 7 and 8 on this machine also so the installers are confusing the version information in the Windows Registry (not too much of a surprise there). Even if we update JDK 6 last, it gets weird too.
Nevertheless, it turns out the Subversion Console uses the Windows Registry to locate the Java install to launch the Console service. Updating the registry entry HKLM\SOFTWARE\JavaSoft\Java Development Kit\CurrentVersion to 1.6 and having a proper install of JDK 1.6 will restore console operation.
When installing DNN 04.09.02 upgrade (from DNN 4.8.4) I receive System.IndexOutOfRangeException: PermanentRedirect error and cannot install the upgrade. How do I get around this so I can install the upgrade?
This thread might help you:
It looks like you have to update it manually... steps are described there.
Also check this thread, might be due to AD if AD is used.
I've re-posted the following from the thread provided by kitsune. Source
First try the following in your browser. Replace "www.yourdomain.com" with your domain:
http://www.yourdomain.com/install/install.aspx?mode=install
If that doesn't work (which it didn't for me) then try the following steps (copied from Chris on that thread).
To manually run the SQL portion of the upgrade you'll need to run each upgrade script between your version and 4.9.2. I upgraded from 4.9.0 to 4.9.2 so I performed the following:
On the web server open the directory: \Providers\DataProviders\SqlDataProvider
Determine which files need to be run. Basically, all of the versions after your old version. In my case I needed to run the files 04.09.00.SqlDataProvider, 04.09.01.SqlDataProvider and 04.09.02.SqlDataProvider.
Open the SQL files in a text editor and replace "{databaseOwner}" (usually with "dbo.") and "{objectQualifier}" (usually with "", but sometimes "DNN4" or some other object prefix)
Run those SQL files in version order using SQL Management Studio.
Assuming those scripts ran without an error then the site should be ready to use.