[Docker] - Disable Libibase For Flowable-UI

Hi everyone,

Currently, I am trying to run Flowanle-UI as a docker image, I need to disable the liquibase function from that image then have run that image with JAVA_OPTS="-Dflowable.database-schema-update=ignore -Dspring.liquibase.enabled=false", however it’s not working. I have access to container and print java process and see that my system properties have injected already

Please give me some advice for that case

https://hub.docker.com/r/flowable/flowable-ui

Can you share your use case? Why would you want to do this?

To answer your question. When I run this;

docker run -p8080:8080 flowable/flowable-ui \
--spring.liquibase.enabled=false \
--flowable.database-schema-update=ignore

The spring properties can be passed as command line arguments (in the latest Docker images).
Or pass them as environment variables; with the -e param or as it has been done in the Docker compose examples in the GitHub repo.

The tables are not created / modified (with the result that Flowable cannot find any tables)

Regards,

Yvo

We will control that script on another service.

This is java process after we run image. It still not working. Anything else are we missing?

how do you know that liquibase actions are still executed?

and again; what is it that you’re trying to accomplish?

In my case, We have a custom engine which run with spring-boot. We want to this custom engine will take responsibility perform all scripts data bootstrapping then we need disable liquibase on flowable-ui.

"how do you know that liquibase actions are still executed?"
=> I have viewed the logs

When I run this;

docker run --rm  -p8080:8080 -e JAVA_OPTS="-Dspring.liquibase.enabled=false -Dflowable.database-schema-update=ignore" flowable/flowable-ui

the startup failed because it cannot find tables; hence disabling liquibase works passing JAVA_OPTS.

Yvo

When I start the container and attach an existing database I see that liquibase executes some read checks to verify that the tables are there and up to date.
Is that what you’re referring to?

Or are you saying that it tries to execute f.e. alter statements?

Yvo

Right, I have existing tables in database. Theoretically I think when we disable liquibase then it will not perform script create tables, however the log showed "cannot create act_adm_server_config already exists"

That is strange. It should only execute read checks.
Is the db version exactly the same? (is this the reason why it tries to create the table?)
Can you share more / complete logs?

Yvo

This is the logs. I put the value is ignore then I think it will not check the version also .

Can you provide the info from the actuators; to see what environment is being created / active.

F.e. http://localhost:8080/flowable-ui/actuator/env

I’m interested in the values of flowable.database-schema-update in propertySources and JAVA_OPTS in systemEnvironment.

It seems there is something strange going on passing the properties as JVM arguments in your case.
I verified it works correctly when it is passed as Spring Boot program argument (in my example --property=value). Could you do it like that?

Yvo

Sorry for the delay in getting back to you.

Here info which I got from http://localhost:8080/flowable-ui/actuator/env. Could you help me check?

Hey @tannth,

It seems that the error you are getting is for the Flowable Admin tables.

The table act_adm_server_config is a table needed for Flowable Admin. Currently the tables needed for the UI Applications (Modeler and Admin) are not using the property that @yvo has been talking about.

Currently, there is property that you can use to disable the creation of the tables needed for the Modeler and Admin. I would suggest that you only create the tables for the Flowable Engines and not the other 2 applications.

You can also provide a PR for the UI Applications in order to support this. Changes for that are needed in the AdminDatabaseConfiguration and the ModelerDatabaseConfiguration. The properties can be added to FlowableAdminAppProperties and FlowableModelerAppPropertie respectively.

Cheers,
Filip

1 Like