Articles, notes and random thoughts on Software Development and Technology
I’ve been spending some time working with Docker recently – it’s incredible technology and understandable why it’s getting so much attention for automating reproducible runtimes.
Here’s a quick 5 min overview covering an overview in 5 mins by Vincent Batts, who works at Red Hat on Docker and OpenShift:
By trial and error I worked this out while building a container running Weblogic Portal 10.3.6 (see my Dockerfiles in the 10.3.6updates branch of my fork of oracle/docker: https://github.com/kevinhooke/weblogic-docker/tree/10.3.6updates).
Even if you do a ‘USER oracle’ followed by a COPY or ADD, the files transferred into the image are still owned by root. This was causing me issues as the WLST script could not read the files owned by root (as you’d expect).
This issue and the justification is described in issue 6119. It doesn’t seem that this will be fixed, it seems like it’s ‘working as designed’.
OpenShift limits the ports that are publicly accessible from your running cartridges. To connect to the WildFly web console on port 9990, you can use the port forwarding:
rhc port-forward yourappname
When it reports the list of forwarded ports, connect to localhost:9990 and logon with your admin user/password.
More info here.
This year at JavaOne 2015 there was a recurring theme across many of the Cloud and DevOp tech sessions that was promoting self-contained deployable Jars (not EARs or WARs) as a more efficient approach for deploying lightweight Java based services. This approach also plays well for a microservices type architecture and can also easily make use of containers, like Docker, PaaS offerings like CloudFoundry or Heroku, or even Oracle’s new Java SE Cloud Services offering.
Being able to deploy small, self-contained services (compared to large, monolithic EARs) brings a whole range of benefits, like being able to deploy more often, and deploy individual services individually without touching or impacting any of the other deployed services.
If you go a step further to consider a deployable unit as a disposable Docker container, then you have to start asking questions about whether a traditional Java EE App Server is still required, or even fits at all this this kind of deployment approach.
Oracle has a supported project on GitHub for Dockerfiles to build images running Weblogic 12c… if you try to do this you also wonder just just how practical it is to even attempt to run Docker containers that are 2GB+ in size… yes, you can do it, but are you really getting the benefits of the lightweight and lean, disposable containers at this point?
I came across this article by James Strachan, “The decline of Java application servers when using docker containers“, which is an interesting read on this topic. The more you look into Docker, containers and lightweight services, you have to question whether Java EE App Servers are losing their relevance. Or at least whether they are relevant for this approach of containerized deployments.