search

alvistack / ansible-role-confluence

Ansible Role for Atlassian Confluence Installation
Apache License 2.0
25 stars 18 forks source link

Not applicable for updating (?) #2

Closed Alex9779 closed 5 years ago

Alex9779 commented 5 years ago

I used your atlassian ansbile roles to set up two production envs which worked like a charm after dealing with some stuff. Now I was testing how to update and found that the roles do not seem to be usable for that. The problem seems to be the extraction of the new packet which is not executed because of the file that is checked which is already there if there is a current installation. So my question is the intention of these roles to always setup new machines? Then just close it and I will figure out myself how to change things to use them for updates too... Cheers Alex

hswong3i commented 5 years ago

Yes you asked a great question: this role skip the upgrade handling, and this is by design (or better say, looking for someone to contribute the idea)

For upgrade, simply DELETE your existing CONFLUENCE_CATALINA then re-run this role with the latest version. After confluence started it will handle its database scheme upgrade internally, and everything should works as expected.

hswong3i commented 5 years ago

From the other point of view, if we will handle the upgrade inside the role, something should be done:

By the way, what if the upgrade fail? Shall we also backup the original CONFLUENCE_CATALINA before delete? Shall we delete the backup once upgrade confirmed as successfully? How about the database backup? This all may need an expertise for handling it in careful...

If you do hope to simplify the installation (and upgrade) overhead, please try my docker image for confluence: just kill the existing container, pull the latest image, then restart the container with original parameters, that’s all ;-)

Alex9779 commented 5 years ago

Ok, yeah I thought about all that stuff you mentioned and I am aware of the problem one can run into... I know your docker images, I run Atlassian stuff on a third implementation with docker, so not with your image. But for my other two environments I host I have other things to take care of, one is ressources for the machines and running as docker containers has one serious disadvantage: as long as you run all the containers on the same machine you have no sort of memory sharing. In my current env I have a QEMU machine for each app so the can share memory for equal pages with KSM and that saves a lot of RAM actually on the host. I could make one docker host so... But then I have a VM with docker an inside the containers for just one app... I don't like that idea so much...

Just one other thing I have to consider doing the upgrade the way you describe: unfortunately your roles are not let's call it "Crowd"-compatible though you provide a Crowd-role... I did that SSO setup manually. And when upgraing I would have to extend the roles to be able to set that SSO stuff or extract the two needed files and reinject them...

Alex9779 commented 5 years ago

To get the current version I have several ideas:

I would check that before getting the archive, no need to get if the version is already installed... And then just as you said, stop the service, delete the app dir and re-run, app home is not touched, database is updated by the app when starting up again...

Still I need a solution for the Crowd SSO stuff... I had a look at another role at Galaxy that does the SSO but the setup is a little different and the owner does not the whole thing because of security reasons he states regarding the needed app password for Crowd. I don't see an issue here, using a vars file encrypted with vault...

I think I am going to write something down... Then we can discuss it...

hswong3i commented 5 years ago 
root@confluence-0:/opt/atlassian/confluence# cat README.txt
------------------------------------------------------------------------------
Atlassian Confluence 6.15.3 - Standalone README
------------------------------------------------------------------------------

I found that JIRA and other else Atlassian apps may also have this version number in README.txt, we could phase it and compare with the current version from yaml.

Alex9779 commented 5 years ago

Sure we could I saw that too but relying on a readme I dont like really... I see no problem using a self crated file. The whole process is not able to catch up a manually installed instance, paths can differ, there are no options to set the paths. On your Crowd role you also cut away the normal ‚/crowd‘ URL so I take it as it is, you have to install with the role the first time and then update with the role, thats it so we can let the role manage the version...

Alex9779 commented 5 years ago

Ok I tested my changes several times and updated my live environment now and all worked quite fine, also the Crowd SSO stuff I added... I also changed the other roles for Crowd, Jira and Bitbucket... Now its up to you to decide if you want it that way or not... I will wait with PRs for the other repos until this is decided here...

pugnacity commented 5 years ago

I'm coming from the puppet world and with voxpupuli/puppet-confluence exists an awesome puppet module. You could use the same logic like in the puppet role.

Install each version of confluence into a seperate folder, based on the version. When check the current version with a little tasks like in confluence_version.rb. When where is a version mismatch, stop confluence install new version, adjust symlink or systemd unit file and start confluence again.

Alex9779 commented 5 years ago

Yeah thats a possible way to do it... My changes work for me and my environment so I‘ll go with them. If you don‘t like just decline the PR, thanks for the basic work of all your Atlassian roles!

hswong3i commented 5 years ago

Please feel free to comment with below idea:

Any idea?

hswong3i commented 5 years ago

@Alex9779 Due to recent 3 commits this issue should most likely solved with a relatively simple way:

Therefore if updated version archive not found from /var/cache/ansible, we will trigger the logic for unarchive package, then remove the legacy binary package and install with the new one. Afterward, handlers being triggered and so service will be restarted serially, too.

Please feel free to check it out ;-)