Make changes to WLS 12.2.1.2 Domain image to comply with environment variables for Domain creation. #460
Conversation
…ted new file domain.properties to define all Domain, Server environemntal variables. Externalized the domain directory by using named data volumes.
Format changed to README
Correction to README.md
Change PRODUCTION_MODE to dev
| admin_username = os.environ.get('ADMIN_USERNAME', 'weblogic') | ||
| admin_password = os.environ.get('ADMIN_PASSWORD') # this is read only once when creating domain (during docker image build) | ||
| admin_password = "ADMIN_PASSWORD" |
There was a problem hiding this comment.
Where does admin_password variable gets the actual value? Here, it will be hardcoded to "ADMIN_PASSWORD"
| domain_name = os.environ.get("DOMAIN_NAME", "base_domain") | ||
| admin_name = os.environ.get("ADMIN_NAME", "AdminServer") | ||
| admin_port = int(os.environ.get("ADMIN_PORT", "7001")) | ||
| admin_pass = "ADMIN_PASSWORD" |
There was a problem hiding this comment.
Sure this will work? admin_pass is now hardcoded to "ADMIN_PASSWORD"
| s=${ADMIN_PASSWORD} | ||
| echo " ----> 'weblogic' admin password: $s" | ||
| fi | ||
| sed -i -e "s|ADMIN_PASSWORD|$s|g" /u01/oracle/commonfuncs.py |
There was a problem hiding this comment.
Oh, I see now... So ADMIN_PASSWORD will be replaced with the actual password. Maybe it would be better if the password was stored in a file, and then read from that file in the WLST scripts instead of using sed to replace a hardcoded string. Otherwise it is hard to understand/debug what's going on
There was a problem hiding this comment.
@Djelibeybi is there any security concern having the generated password set as environment variable? I mean... that information is accessible to any user in the host that can run docker, sure, but if there is such user, that user can also shutdown the container and do way worse things anyways... It's like trying to protect the kitchen from a thief who already got inside the house, and has plenty of time to inspect and workaround whatever is securing the kitchen... :P
There was a problem hiding this comment.
Avi the problem here is that the AdminServer container as well as Managed Server containers all need to use the same exact Admin Password. I auto generate the password but I need to allow the users override that auto generated password to be anything they want to set.
There was a problem hiding this comment.
It's not great, but the same method is used by lots and lots of images, and there are a lot worse options. I'm OK with it.
| ADMIN_HOST=wlsadmin | ||
| CLUSTER_NAME=DockerCluster | ||
| PRODUCTION_MODE=dev | ||
| ADMIN_PASSWORD=welcome4 |
There was a problem hiding this comment.
If password will be generated, should it be here?
There was a problem hiding this comment.
Yes this would be the perfect spot to generate the password but this is not a shell script but a env file. How do I call a function that auto-generates the password at runtime for the AdminServer and then when the Managed Server runs it uses the same password generated for the Admin Server.
There was a problem hiding this comment.
We can't accept any hard-coded passwords. Can you remove this and manually set it on container start somehow? Though, I may be misunderstanding how this interacts with createServer.sh.
There was a problem hiding this comment.
Yes the domain.properties is the same as using the -e property in the command line. I can delete the admin password from domain.properties and have the user enter the admin password using -e. The pain is that both the Admin Server and Managed Server need to have access to the same password. If the user is over writing the password they would need to use the -e on both docker run command lines to set the admin password. If the password is auto generated in the admin server docker run then the user needs to find the password in the docker logs and then pass it with -e command line when running the managed server container. I am investigating if there is a way around this.
There was a problem hiding this comment.
I actually have no problem with this: anyone who orchestrates can provide the same value to both containers. As long as it's clearly documented how to find the password and how to provide it to the managed server containers, it's all good with me.
Which means I reckon you should just remove this line from domain.properties and just rely on documentation.
There was a problem hiding this comment.
According to Global Product Security, we can't accept any images that have any hard-coded passwords. If the environment file setting is ignored or overridden, that's OK. If not, it needs to be removed and reworked somehow.
I'm holding off on actually requesting changes until someone explains if that hard-coded password is actually used.
| s=${ADMIN_PASSWORD} | ||
| echo " ----> 'weblogic' admin password: $s" | ||
| fi | ||
| sed -i -e "s|ADMIN_PASSWORD|$s|g" /u01/oracle/commonfuncs.py |
There was a problem hiding this comment.
It's not great, but the same method is used by lots and lots of images, and there are a lot worse options. I'm OK with it.
| ADMIN_HOST=wlsadmin | ||
| CLUSTER_NAME=DockerCluster | ||
| PRODUCTION_MODE=dev | ||
| ADMIN_PASSWORD=welcome4 |
There was a problem hiding this comment.
We can't accept any hard-coded passwords. Can you remove this and manually set it on container start somehow? Though, I may be misunderstanding how this interacts with createServer.sh.
|
I am curious whether the Manager Server could join the domain successfully after this changes, I do not see related changes in createServer.sh I developed a same patch, Admin server could startup successfully and manager server always failed to join due to invalid username or password. I do provide the correct username and password indeed. I really have no idea about about what is going wrong there. |
|
@BluZed try again make sure you follow instructions in README. You need to manually make sure to enter the same password as the one used in the admin server container, either the auto-generated one or the one you enter with the -e option. |
|
@mriccell I wanna know whether the Manager Server could join the domain successfully after this changes, if so that would be great, I can read it to know what is going wrong in my side after merging. |
|
@bluezd yes the Managed Server can join the domain/cluster after these changes. |
Resolve Issues #452 and #449.
Made following Changes
1- Create WebLogic domain at runtime.
2- Define environment variables at runtime in file domain.properties and pass them in at runtime by using --env-file option. Set:
ADMIN_NAME, ADMIN_PASSWORD, ADMIN_USERNAME, ADMIN_HOST, DOMAIN_NAME, MS_PORT, PRODUCTION_MODE, DEBUG_FLAG, CLUSTER_NAME.
3- Externalize DOMAIN HOME by mapping the domain to a data volume so that Admin Server and Managed Servers can all write/read to the same DOMAIN_HOME.