AlfrescoArchive / acs-community-deployment

NOTE: This repository is now deprecated and archived as the https://github.com/Alfresco/acs-deployment repository is now the centralized place to find containerized deployment artefacts and documentation.

Home Page:https://hub.alfresco.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

docker-compose not working reliably

PaulDebus opened this issue · comments

Hey,

I am having trouble getting Alfresco community to run via docker-compose. I downloaded the docker-compose.yml from the 2.2.0 snapshot and tried it on different machines. The issue I am facing seems similar to #64, as on one machine, I am never able to log in, whereas on the other machine, everything just works fine.

On the machine, where it does not work, I get a lot of errors like this:

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dialect': FactoryBean threw exception on object creation; nested exception is org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (The connection attempt failed.)

together with many Java errors. I thought docker would end the problem of "but it worked on my machine", but this is somehow the case here.

Thank you in advance for your support, if there is anything you need to know or I can test, just let me know

Hello @PaulDebus
I have checked out locally tag 2.2.0 of this project and run the docker-compose file. In my case Alfresco has started successfully.

The error you have described looks like a database problem. First step is to make sure that the PostgreSQL container is up.

  1. Please make sure that before you start the docker-compose environment port 5432 is not allocated (have an already running instance of PostgreSQL).
  2. After you encountered the above error just run docker ps command and verify that PostgreSQL container is still up, if not please provide logs.

Another common problem might be that the allocated docker memory is not enough for running all the containers and some of them suddenly shut down. In the 'header' section of the docker compose it is specified the following:

This docker-compose file will spin up an ACS cluster on a local host or on a server and it requires a minimum of 12GB Memory

Depending on your machine, I would suggest to increase Docker memory to at least 4GB (6GB for a smoother experience) for a test environment/deployment(and even further if you have other containers started).

If this not solve the problems please provide us additional information about your system (OS, Docker, Docker-compose version, CPU, RAM, PostgreSQL container logs even the docker-compose file might help)

Hey, thanks for the response!

I also checked on a second machine, where everything runs fine. So the memory thing seemed plausible for me. So first some hardware information: I am using a QNAP TS-EC1680U with 32GB of RAM, running some version of Linux 4.2.8. Docker version is 17.09.1-ce and docker-compose version is 1.22.0. I am using the exact docker-compose file that is on the 2.2.0 snapshot of the repo, so postgres image version 10.1. No other docker containers are running on the host.

The result of running the postgres container (together with all others) for the first time after a cleanup is the following log:

waiting for server to shut down....2019-08-15 13:05:47.559 UTC [42] LOG:  aborting any active transactions                          
2019-08-15 13:05:47.561 UTC [42] LOG:  worker process: logical replication launcher (PID 49) exited with exit code 1                
2019-08-15 13:05:47.562 UTC [44] LOG:  shutting down                                                                                
2019-08-15 13:05:47.586 UTC [42] LOG:  database system is shut down                                                                 
 done                                                                                                                               
server stopped                                                                                                                      
                                                                                                                                    
PostgreSQL init process complete; ready for start up.                                                                               
                                                                                                                                    
2019-08-15 13:05:47.674 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432                                                
2019-08-15 13:05:47.674 UTC [1] LOG:  listening on IPv6 address "::", port 5432                                                     
2019-08-15 13:05:47.678 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"                                  
2019-08-15 13:05:47.947 UTC [69] LOG:  database system was shut down at 2019-08-15 13:05:47 UTC                                     
2019-08-15 13:05:47.953 UTC [1] LOG:  database system is ready to accept connections 

Before starting the containers, port 5432 was free, after the start the postgres is running and I can interact with it fine via other tools. I tried the pgadmin tool and was able to read and modify data easily.

As I am running on Linux there is now way (as far as I understand docker) to increase the RAM available to docker, as it may use the entire RAM the machine has. Monitoring the resource usage while starting the containers, I saw no big increase in RAM usage overall, just some CPU usage while the containers were starting, going down to around 0% after that. RAM usage never went over 15%.

Thank you a lot for your support, if I can provide anything more, just let me know.

This is interesting, PostgreSQL logs seem to be fine and you are right regarding the increase of docker RAM usage on Linux.
I'm a windows user and I don't know if firewall or any linux policy might be of fault here.

Please provide the docker-compose file, meanwhile you can try:

  1. Upgrading docker/docker-compose (I'm currently using 2.1.0.1 and compose 1.24.1)
  2. Checkout deployment project again (tag 2.2.0) or try a different version/tag of the docker-compose deployment (2.0.0/master)

Here is the docker-compose file I am using. I had to change some ports due to collisions.
docker-compose.txt

I cannot update docker or docker-compose, as the QNAP software is a really limited version of Linux, without much of package management.

I tried tag 2.0.0 and it shows the same errors and the same behaviour of not letting me log in.

Quick follow up: I tried again with the latest version of the docker-compose.yml from github. Now, all the containers start up fine, no errors.

The problem now is, that I have to change the port, where alfresco is reachable from 8080 to something else. I have not yet found the correct combination of changes in the compose file, to make it work. The page starts loading, but nothing ever shows up. Can you give me a hint on how to deploy alfresco on a different port?

Thanks and regars
Paul

Hello @PaulDebus Did you ever figure out how to run alfresco on a different port? I have been trying a lot of combinations but nothing seems to work.

Hey @roland-d, I did not. Not really. I ended up setting up a VM where I run the alfresco docker and a nginx proxy on the main machine to forward to that VM. It is not a solution I am happy with, but it works....

@PaulDebus Really appreciate you getting back to me, thank you for the update.

Firstly, thank you for raising this issue and apologies for the time it's taken to respond.

As you may have seen from the recent blog post (https://hub.alfresco.com/t5/alfresco-content-services-blog/acs-community-repositories-consolidation/ba-p/302770) we have been consolidating the deployment repositories and this one is being archived.

It sounds like this issue has since been resolved, if not, please try again using the https://github.com/Alfresco/acs-deployment repository and if necessary create a new issue in that repository.