I have noticed that the docker-compose version as installed by default, is old (1.6.2). Can I update the version or will I destroy something?
Related
I am trying to use the new docker ecs feature, but just get an error 'ecs' is not a docker command.
Using the latest version of docker edge on macOS 10.15.7
Do I need some additional steps to activate the docker command?
For anyone who was following documentation they found about docker ecs written previous to some development changes - while it used to be a plugin, ECS integration is now part of the docker cli itself.
This document covers how to set it up using a context
https://docs.docker.com/engine/context/ecs-integration/
We're running an older version of artifactory in a kubernetes cluster that uses the postgresql database chart included with artifactory. The chart 7.18.3 was used to standup the artifactory instance. With the latest vulnerabilities report, we decided to upgrade our artifactory to the latest version. It was recommended to step up through the various revisions to make sure that the postgresql gets the necessary changes to go to the latest version. So I decided to upgrade to the 8.4.7 chart before upgrading to the 9.2.9 chart. I've read the README included with the charts and made sure that my database was ready for the upgrade. I didn't pass in a password for the database when I initially setup the artifactory instance so I pulled the existing password before upgrading. I then perform the upgrade as directed by the readme with the flags --set databaseUpgradeReady=yes and --set postgresql.postgresqlPassword=${POSTGRES_PASSWORD}. I'm getting a 404 error after the upgrade:
Message /artifactory/webapp/
Description The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
One thing that I noticed is that prior to the upgrade there is only one artifactory-postgresql service and after the upgrade I have two postgresql services: artifactory-postgresql and artifactory-postgresql-headless.Digging into it, the headless service is created when a clusterIP is not passed in, but I haven't seen a way to pass the clusterIP to the artifactory-postgresql chart included in artifactory. Any help would be appreciated.
Artifactory Upgrade using postgresql from 7.x to 9.x chart versions is a two step process
First upgrade 7.x to 8.x (Manual process involves export/import of data)
Then upgrade 8.x to 9.x chart versions
Please refer below for detailed steps :
https://github.com/jfrog/charts/blob/master/stable/artifactory/UPGRADE_NOTES.md
Note: For faster responses for your issues , Feel free to raise issues directly here
I am looking to upgrade from PostgreSQL to Aurora PostgreSQL and running into an issue when trying to test an upgrade in my CFT I specify the EngineVersion for my DB Cluster as 9.6.11 but I can’t update that to 9.6.12 as it requires a replacement of the cluster stack. If i deploy my stack out without the EngineVersion for the Cluster then it defaults to 9.6.9 which is below the version I want PostgreSQL at. I was able to upgrade the Cluster from 9.6.11 to 9.6.12 via the CLI but when i updated the EngineVersion in the CFT for the cluster to 9.6.12 it still wanted to create a new Cluster Stack even though the version was changed to 9.6.12 via the CLI. Is there a good way to get around this using CloudFormation?
This is an old question, but I'm running into the same problem while trying to upgrade from Aurora Postgres 9.6.11 to 10.11. CloudFormation wants to replace the cluster which wipes out the database. I think what we need to do is the following:
Use Console or CLI to update the Engine version
Snapshot the database
Delete the CloudFormation stack
Rebuild the CloudFormation stack restoring from the Snapshot taken in step 2
This seems a little wonky to me, but I'm not sure how else to update the engine version and also get CloudFormation in sync with the resources. Using the Console or CLI to update the engine version will cause drift in the template, so the only recourse is to delete the stack and recreate it.
I want to upgrade my cluster to use the newest version of Kubernetes. I see Google Container Engine has the following tool:
https://cloud.google.com/container-engine/docs/clusters/upgrade?hl=en
However, after I upgrade my cluster and everything finishes successfully, when I see my cluster on the web console I still see the old version (1.9.3). When you create a new cluster version is 1.0.1, so I expect my cluster to upgrade to that version. I also tried upgrading to 0.21.4 with the same results.
Is there something I'm doing wrong?
The web console may be reporting your initial cluster version rather than the current version of you master and nodes. If you want to see all of the versions for your cluster, try running
gcloud beta container clusters --zone=<zone> describe <cluster-name> | grep -i version
and it should print out something like
currentMasterVersion: 0.21.4
currentNodeVersion: 0.19.3
initialClusterVersion: 0.19.3
If your initial cluster version was 0.19.3 then your master won't have been upgraded to 1.0.x yet (but you should have received a notice that you will be upgraded soon).
Once your master has been upgraded, you can follow the instructions at the link you found to upgrade your nodes to the same version as your master.
i have one server with redmine 1.2.1 and webrick webserver. In another new ubuntu server, i've just installed redmine 1.3.0 from the main repo, with apache+passenger. No problem with that.
Then i pg_dumped my old 1.2.1 database and put into my new postgresql for my 1.3.0 redmine. Everything works well except one thing. when i go to watch one of my repos (url like http://myhost.com/projects/myproject/repository/revisions/11806) I get this error
ActionView::TemplateError (PGError: ERROR: relation "changeset_parents" does not exist
This means that i didnt upgrade correctly my redmine, is there a way to upgrade this database in my new ubuntu server?
Thanks a lot.
Did you run the Redmine Database migration script?
rake db:migrate RAILS_ENV=production
This will need to be run as a root user in from the /usr/share/redmine directory or whereever you have installed Redmine to.