Simple Docker GUI for monitoring and managing containers and images – in combination with Vagrant and VirtualBox

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

I came across a simple Google Chrome Addon called Simple Docker GUI. It provide a GUI that allows for easy insight in and some management of Docker containers and images. Because the tool connects to the (remote) Docker API across HTTP, it can used on a different machine than the one running the Docker Engine. Because I am typically using Vagrant to spin up a Docker Host VM and subsequently the Docker Containers inside that host, it is convenient to keep a tab on things from the (Windows) Host machine. Using this Simple Docker UI, that is exactly what I can do. The layout is shown in the next figure:

Vagrant talks to VirtualBox, allows me SSH into the Docker Host VM and talks to the Docker engine regarding stopping and starting containers. From within the Docker Host VM, I can open a terminal window and start interacting with the CLI (command line interface) for Docker. The Simple Docker UI adds a perspective: browser based user interface that interacts too with the Docker engine (running inside the Docker Host VM) and presents information in an easy format.

 

image

To get started with Simple Docker UI, I went through the following steps:

Add Simple Docker UI as add on in Google Chrome from Chrome App Store:

image

Start Simple Docker UI from App Launcher

image

The App appears in a popup window – opening the Settings tab. Here is where we have to specify the IP address for the Docker Host VM (as specified in the DockerHostVagrantFile in my case where I set up a private network with IP address 10.10.10.30 for the Docker Host VM). This tab provides detailed instructions for configuring Docker on the Docker host in order to expose the remote API.

SNAGHTML47ba1c2

On Ubuntu 14.04, I had to make a small change to a Docker configuration file (/etc/default/docker)  – specifying that fact the Remote API should be exposed and the port number at which it be exposed:

image

After saving the file, Docker has to be restarted for the changes to take effect:

sudo service docker restart

Using a simple ping from the browser (http://10.10.10.30:2375/_ping) I can verify that the Docker API can be accessed

image

I have to configure the IP address and port on the Settings tab:

image

and now on the Containers and Images tabs, the details for the Docker engine are available and admin-operations can be performed:

image

drill down to images:

image

Look at containers:

image

And drill down to details:

SNAGHTML4800017

Containers can be started and stopped from this page and through the terminal we can directly interact with the container.

The history of a container can be inspected:

image

 

Even though it is only early days for this tool – still in beta – it looks very promising to me and is even in its current state already quite useful!

Resources

https://chrome.google.com/webstore/detail/simple-docker-ui-beta/jfaelnolkgonnjdlkfokjadedkacbnib?hl=en

https://github.com/felixgborrego/docker-ui-chrome-app 

Alternative: Shipyard – https://shipyard-project.com/

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Most aggravating developer induced headaches for Middleware Administrators

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

In recent months, I have had a lot of dealings with middleware administrators, responsible for the management of WebLogic Server and other Fusion Middleware components such as SOA Suite, Oracle Service Bus, WebCenter and UCM. My role is frequently one that allows me to step back a little and observe. These observations made it very clear that not only is middleware administration a challenging task – one that is underestimated in many organizations – it is also one that is frequently made much harder than necessary by actions that developers take or do not take. Developers create the artifacts that administrators will deploy and manage on the middleware infrastructure. These developers can make life easier for the administrators if they adhere to certain best practices in creating and handing over these artifacts. However, out of ignorance, disinterest or lack of time it is unfortunately common for administrators to experience severe frustrations over the work of developers.

I am trying to compile a list of various points of frustration for middleware administrators caused by developer ignorance or carelessness. Below is the list if have compiled so far – with some help from middleware experts Jacco Landlust, Edwin Biemond and Simon Haslam. If you – yes dear reader, you! – can help me in naming other frequent frictions between development team and administrator, please write a comment on this article. Your help is of course much appreciated.

Note: the purpose of this article – apart from encouraging middleware administrators – is to try to help make clear to middleware developers how they can contribute to the run time success of the software they create – by the way the only success that really counts.

Continue reading

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Organizing Fusion Middleware administration in a smart and frugal way

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

One of the perhaps somewhat counterintuitive challenges with at least the initial stages of adopting Fusion Middleware is the fact that there is too little work in terms of administration.

On the one hand, Fusion Middleware administration entails quite a bit, starting with WebLogic Server

clip_image002

and typically extending to one or more FMW components:

clip_image004

all of which the administrator – or rather the administration team – needs to deal to with. Typically even around the clock to ensure the availability required by the business.

On the other hand, the actual workload for FMW administration for a small number of applications, services and processes does not justify a dedicated resource. This proves a serious problem for many organizations: 24/7 availability requires 3 FTE while the effort is on average less 0.5 FTE.

Organizations can adopt several strategies to address this challenge, as is illustrated in the next picture.

Continue reading

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

WebLogic 12c: Use JPA in your Web Application

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Where as in WebLogic 11g JPA was not support by default, in WebLogic 12c it is the default persistency provider.JPA 2.0 is part of JAVA EE 6.

I was trying some new JAVA EE 6 features in WebLogic 12c, so here is a is a way to create a Web Application with JPA under WebLogic 12c

Some of the JAVA EE 6 specifications we’re already supported in WebLogic 11g. JPA 2.0 was one of them. Though version 1.0 was the default. 2.0 also worked.Unless an explicit <provider>…</provider> wass specified in the persistence.xml file of a deployed application, WebLogic 11g used OpenJPA/Kodo by default.

The default JPA provider setting is exposed via a new MBean: JPAMBean on the DomainMBean, and persists the configuration into the config.xml file.

Furthermore, you needed to install the patch QWG8 – Enable JPA 2.0 support on WebLogic Server.

To make it work on 11g, you had to use Oracle TopLink as the persistency provider like the image shows you in the WebLogic Admin Console

Now for 12c this is not needed anymore, TopLink will be the default JPA Provider

Continue reading

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Clone your Oracle FMW SOA Suite 11g

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Sometimes, you would like to have an extract from a SOA Suite 11g  production environment to test it in a test or acceptance environment.

There are several ways to do this, but in this post I’d like to discuss about how to get a clone of your SOA Suite 11g, from one WebLogic Server host to another.

To extract a clone, you will have to determine which components should be cloned:

  • The SOA repository schema’s, like MDS, SOA-INFRA and so on.
  • The WebLogic and FMW software
  • The SOA Suite Domain Configuration including all SCA components and other deployments.

Continue reading

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page