dotcms / docker Goto Github PK

Public repository for Docker artifacts

License: Apache License 2.0

Dockerfile 19.19% Shell 75.57% Java 5.24%

docker's Introduction

dotCMS docker

Public repository for various dotCMS Docker artifacts. Please note that as of 21.06 the offical dotCMS Dockerfiles and build artifacts are part of the core repo and can be found here: https://github.com/dotCMS/core/tree/master/docker

Older Dockerfiles

If you are looking for older version of the dotCMS Dockerfile, they can be found undeer the archived directory here https://github.com/dotCMS/docker/tree/master/images/archive

License

The Docker resource files for dotCMS-distributed images are licensed under the Apache License 2.0. See the LICENSE file for more details.

docker's People

Contributors

Stargazers

Watchers

docker's Issues

Permission and npm issues building and running docker image

We have 2 issues building and running our current docker image.

Building from src fails because alpine bumped up the node version they install via apk in their 3.9 image which we do not support.

docker build --build-arg BUILD_FROM=COMMIT --build-arg BUILD_ID=origin/master -t dotcms-test .

Once the docker image is created, it fails to run in different environments due to permissions issues on startup. This is reproducible on my local docker install (OS-X / brew) and on Amazon's Linux2 install.

05-setup-app-storage can fail

Fails when trying to make the /srv/home directory.

Up default tomcat threads

In high performance environments, tomcat's thread pool can become exhausted even while there are plenty of resources and headroom in java to handle more load. We need to change our default to allow tomcat to accept and serve more traffic out of the box.

ES Configuration Variables Ignored in dotCMS version 5.3.5 docker image

Bottom line, prior to 5.3.5 we used PROVIDER_ELASTICSEARCH_PROTOCOL, PROVIDER_ELASTICSEARCH_DNSNAMES, and PROVIDER_ELASTICSEARCH_PORT_HTTP to set ES client settings in the docker image.

With 5.3.5 these variables exist but are effectively ignored and PROVIDER_ELASTICSEARCH_ENDPOINTS must be used instead.

Recommendations:

Remove these ignored variables - don't see a real reason to have multiple ways to set the same settings. Just leads to possible confusion and bugs like this one.
Alternatively fix the dotcms-config-cluster.properties so that it only sets ES_ENDPOINTS if PROVIDER_ELASTICSEARCH_ENDPOINTS has a value.

Details

Problem was introduced here: dotCMS/core#18870
As you can see if ES_ENDPOINTS here is set, getDefaultEndpoint is never called which basically causes the ES_HOSTNAME, ES_PROTOCOL, and ES_PORT to be ignored. As you can see here, ES_ENDPOINTS is always set in the Docker container.

Documentation

If the previous settings are going to be ignored or removed, should be documented in the documentation. I saw the example configurations changed but I did not see any documentation that indicated that the docker config for 5.3.x would no longer work with 5.3.5.

Content import and exports limited to 10,000?

Customer indicated that exports and imports from content search screen seem to be limited to 10,000 - is this specific to dockerized version or an issue with 5.x?

Customer had a valid license file applied to the the server at the time.

Auto login failed (No user found)

I'm trying to deploy dotCMS 5.3.9 docker image (dotcms/dotcms:5.3.9) in an Ubuntu VM. I'm getting an error when running docker-compose up using the yaml file provided for the 5.3.8.4lts image here: https://github.com/dotCMS/docker/blob/v5.3.8/examples/02-single-node-demo/docker-compose.yml
The error is about the login, which apparently the application fails to do by its own, and I can confirm that I am unable to do so manually through the browser as well.
A preview form the logs I attached:
[10/05/21 08:59:55:568 GMT] INFO util.SecurityLogger: class com.dotmarketing.cms.login.factories.LoginFactory : Auto login failed (No user found) from IP: 172.21.0.1 : com.dotmarketing.exception.DotRuntimeException: Could not execute query -- ip:172.21.0.1,user:null [10/05/21 09:00:10:606 GMT] WARN util.JDBCExceptionReporter: SQL Error: 0, SQLState: 42P01 [10/05/21 09:00:10:606 GMT] ERROR util.JDBCExceptionReporter: ERROR: relation "user_proxy" does not exist Position: 1564
The only change I have made in the yaml file is to change the version of dotcms docker image from latest to 5.3.9.
Thing I have tried:

To deploy the dotcms/dotcms:5.3.8.4lts image. Resulted in the same error.
To deploy the latest image and it works fine, but I need specifically the 5.3.9 version.

I'm attaching the logs where the problem can be seen more clearly.
dotcms.log

hazelcast:3.9.2-os docker image cluster does not create a single cluster.

When using the official dotcms/hazelcast:3.9.2-os image in a Deployment/replicaset with more than one replica, the instances of hazelcast do not create a single cluster.

To reproduce:
This can be reproduced locally via docker-compose for simplicity or in a kubernetes cluster.

Via docker-compose:

Using the docker-compose.yml from here: https://github.com/dotCMS/docker/blob/master/referenceImplementations/03-full_stack/docker-compose.yml
Run docker-compose up -d --scale dotcms=0 --scale db=0 --scale elasticsearch=0 --scale elasticsearch-statis=0 --scale hazelcast=3
Then exec into the pod by running docker-compose exec hazelcast sh
From inside the pod run wget -O- hazelcast:5701/hazelcast/rest/cluster several times.
Notice the member size reported is always 1. Notice the member reported is always marked with "this".

Via kubernetes:
Given the attached file hazelcast-deployment.yml, which is a stripped down version of
https://github.com/brentgriffin/2018BootcampK8sDemo/blob/master/deployment.yaml with replicas set to 3. And a Kubernetes cluster:

Run kubectl apply -f hazelcast-deployment.yml to deploy hazelcast to kubernetes cluster
After deploy, find the pod names for hazelcast and pick one: kubectl get pods
Run kubectl exec -it {podname} sh
From inside the pod run wget -O- hazelcast-svc:5701/hazelcast/rest/cluster several times.
Notice the member size reported is always 1. Notice the member reported is always marked with "this".

Create YAML to deploy dotCMS image in OpenShift

Regex in dotmarketing-config.properties file being mangled by templating process

This value is being modified during the templating process:

##Static Push Bucket Name Restrictions
STATIC_PUSH_BUCKET_NAME_REGEX=[,!:;&?$\\\\*\\/\\[\\]=\\|#_@\\(\\)<>\\s\\+"]+

Result is that static push to s3 fails because the regex statement is not valid

Logs from attempted push:

13:26:43.787  INFO  publishing.PublisherAPIImpl - Start of Bundler: c
13:26:43.831  INFO  publishing.PublisherAPIImpl - End of Bundler: c
13:26:43.831  INFO  publishing.PublisherAPIImpl - Start of Bundler: FileAssetBundler
13:26:43.832  INFO  bundlers.FileAssetBundler - +structuretype:4 +(path:/quest-logo.svg ) +(conhost:48190c8c-42c4-46af-8d1a-0cd5db894797  )
13:26:43.870  ERROR staticpublishing.AWSS3Publisher - Unclosed character class near index 26
[,!:;&?$\*/[]=|#_@()<>s+"]+
                          ^
java.util.regex.PatternSyntaxException: Unclosed character class near index 26
[,!:;&?$\*/[]=|#_@()<>s+"]+
                          ^
    at java.util.regex.Pattern.error(Pattern.java:1957) ~[?:1.8.0_212]
    at java.util.regex.Pattern.clazz(Pattern.java:2550) ~[?:1.8.0_212]
    at java.util.regex.Pattern.sequence(Pattern.java:2065) ~[?:1.8.0_212]
    at java.util.regex.Pattern.expr(Pattern.java:1998) ~[?:1.8.0_212]
    at java.util.regex.Pattern.compile(Pattern.java:1698) ~[?:1.8.0_212]
    at java.util.regex.Pattern.<init>(Pattern.java:1351) ~[?:1.8.0_212]
    at java.util.regex.Pattern.compile(Pattern.java:1028) ~[?:1.8.0_212]
    at java.lang.String.replaceAll(String.java:2223) ~[?:1.8.0_212]
    at com.dotcms.enterprise.publishing.staticpublishing.AWSS3Publisher.a(SourceFile:453) ~[ee-5.1.5.jar:?]
    at com.dotcms.enterprise.publishing.staticpublishing.AWSS3Publisher.a(SourceFile

Continual Hazelcast Messages

Describe the bug

In the more recent container builds of dotCMS, Hazelcast is continually logging a WARNING message relating to metrics.

Steps to reproduce
Deploy a recent dotCMS container and tail the log file.

Expected behavior
Subsequent log events relating to the same metric should be suppressed in an effort to conserve log file size and readability.

Additional context
This has been tested and known to occur on versions 21.02.2, 21.02 and, formally, 5.3.8.4lts. Upgrading Java or simply issuing apk update and apk upgrade commands at container build time have been reported and tested as fixing the problem.

Configure Secure Cookies via Environment variable

Be able to affect whether or not dotCMS will serve Secure Cookies (https://dotcms.com/docs/latest/cookie-use#Properties) via environment variables

Hazelcast 3.9.2-alpha cluster unreliable

Starting up a cluster using 3.9.2-alphs, if all pods are started at once they will join separate clusters, only by starting a single pod first can you be confident that they will most likely join a single cluster.

Problem starting up docker container in isolation

We seemed to have broken something with dotCMS container. I was running some regression test and just starting up dotCMS container all by itself with this command:
docker run -itp 8080:8080 dotcms/dotcms:5.1.6-osalpha

On startup it hangs for a very long time after this line in the log:
Building Cache : pagemultitreesworking, size:1000,Concurrency:32

See log file summary, threaddump, and full log file here: https://gist.github.com/brentgriffin/0d5e7638dc015d14695904baa4219dd6

dotCms is not able to connect to elasticsearch

I'm facing the following issue while trying to run dotCms docker-compose

ERROR business.ESIndexAPI - Elasticsearch Attempt #14 : elasticsearch: Name does not resolve

The problem seems to be the connection between dotCms and elasticsearch container but I'm not able to find exactly the root cause. Can you please check the below log file and tell me if there's something that needs to be done/changed?

docker-compose.yml: "02-single-node-demo"
log.txt

Thanks!