Posts tagged with 'docker'

Description:

The Eclipse JavaScript Development Tools have reached a new level of features and usability with Eclipse Neon. Many things were implemented as part of the JSDT 2.0 release that is now available with Eclipse Neon. This webinar demonstrates the following new features:

The talk also features plans for the future of JavaScript development in Eclipse IDE.

The slides for the presentation are available here.

Description:

Docker is awesome, but how to use it well when doing development? In this talk you will get a quick introduction on how to use Docker effectively, especially for development from within Eclipse. We will show how the release of Eclipse Neon supports Docker to make it even more integrated into your day-to-day work from within your IDE. In particular, you’ll see how you can pull and run an image for a database, build a custom image for an application server, run it and deploy an application using data volume, exposed ports and container links. We will also take a look at some of the newest features, such as support for Docker Machine, TM Terminal integration, run configurations for containers, and a variety of other UI improvements.

The slides for the presentation are available here.

Other webinars have also been recorded and are available on the Eclipse Neon Webinar Series on Youtube.

Enjoy !
Xavier Coulon
@xcoulon

We’ve added icon decorators on the containers to show their state. This makes it clearer if a container is running, paused or stopped.

We’ve worked on the workflow to pull and search images from Docker Hub. The updated 'Pull Image' wizard can be launched from the 'Docker Images' view or from the 'Docker Explorer' view (a new context menu entry is available on the connection node and on the 'Images' node)

The wizard detects the tag in the image name and if none is specified, the image tagged latest will be pulled.

If the user needs to search a specific image name, she can click on the 'Search…​' button which will open the 'Search' wizard:

followed by a second page that displays all the tags for the selected image:

Even though this wizard can only search from Docker Hub, users can nonetheless pull images from other third-party registries. In that case, image name needs to be prefixed with the registry host and port, such as 192.168.59.103:5000/centos:7.

Finally, we`ve also added a new launcher to build images from a Dockerfile.

The source path is a directory in the workspace or on the file system and the 'Docker Connection' combo box specifies on which Docker daemon the image will be built.

As always, feedback, feature requests and bug reports are welcome. Since this tooling is developped at Eclipse.org, you can join us on our public mailing-list or use Bugzilla to report any bug or feature request.

Have fun !
Xavier Coulon
@xcoulon

We wanted to have a way to easily start/stop and deploy Docker containers directly from Eclipse.

We wanted something that would run on all three major platforms: Windows, Linux and OS X.

We wanted something that would work together with existing Docker command line tools, but also utilized provide better overview and easier/faster access to common operations, from a visual perspective.

We wanted it to be released with Eclipse Mars.

…​and that is what we got now.

This article runs through how to get it installed, the main features and what the future plans are.

With Eclipse Mars released, you can get it from the Eclipse Mars updatesite, the feature is named Docker Tooling.

If you want to try the latest greatest builds you can use Linux Tools project nightly builds update site at http://download.eclipse.org/linuxtools/updates-docker-nightly/

To use the plugins, it is assumed that Docker is already installed. You can see Docker’s Installation guide on how to do this on various platforms.

Once you have installed the Docker tooling, you will get access to three new views:

The easiest way to get to see these are by opening the Docker Tooling perspective.

In the screen above, the Docker tooling are connected to a locally running Docker deamon named boot2docker.

To configure this you click the Add Connection…​ button in the Docker Explorer view.

This will start a wizard that will try to detect your default Docker connection setup, dependent on your operating system.

In Linux it will use standard unix sockets and if on Windows or OSX, it will look for the following environment variables: DOCKER_HOST, DOCKER_TLS_VERIFY and DOCKER_CERT_PATH.

If neither of these are detectable, you can click Use custom connection settings and provide the connection info.

When you have the connection working you can get started using Docker images.

To pull an image, you use the Pull Image in the Docker Image view.

Here, I’m simply pulling the jboss/wildfly image, a image amongst many available at http://hub.docker.com.

To run the image, the easiest way is to right-click on the image in the Docker Explorer.

Here, I’ve initially filtered the list to just show images matching wildfly and then using right-click to choose the Run Image…​ action.

From within this dialog you can also search in Docker Hub for other images by clicking Search…​.

In this example, I’m only going to focus on running using the defaults, but in the Run Image wizard you can also configure ports, links, volumes, environment variables etc.

By default, we enable interactive and tty mode to allow you to interact with the docker container in the console (i.e. if the image asks for input).

When you click Finish, the container will start and show output in a Console and the Docker Containers view will show which ports are used.

In here, the port at 8080 (the web server) is mapped to 32768 on the docker daemon.

To show this I just need to goto http://dockerhost:32768 to access it. dockerhost is the IP of the docker daemon.

If you have a Dockerfile you can build it via the hammer icon on the Image view. This will start the Build wizard.

Once built, the image will show up and be possible to use for running.

You can view properties for all the various parts: connection, image and container, including getting a tree view of what docker inspect would show.

For Eclipse Mars we added all of the above base features and you can use it in your day-to-day work with Docker.

For Eclipse Mars SR1, we will work on getting some of the rough edges fixed, like 'Run' and 'Build' should be available in the context menu and not only in the views menu.

Work also started in Eclipse CDT to support using Docker images to build binaries for an OS other than the one you are running on. The vision for this would allow running on Windows or Mac, but target native deployment on multiple various Linux architectures.

Furthermore in JBoss Tools we are working on better integrating Docker with Eclipse server adapters, to ease deployment of your web applications to a Docker container. You can see how server deployment works with the current Docker tooling by leveraging docker volumes and remote deployment support.

If you have suggestions or find bugs, please open these in the Linux Tools project under Docker.

Have fun!

Max Rydahl Andersen
@maxandersen

The Docker Explorer provides a wizard to establish a new connection to a Docker daemon. This wizard can detect default settings if the user’s machine runs Docker natively or in a VM using Boot2Docker. Both Unix sockets on Linux machines and the REST API on other OSes are detected and supported. The wizard also allows remote connections using custom settings.

The Docker Explorer itself is a tree view that handles multiple connections and provides users with quick overview of the existing images and containers.

Built-in filters can show/hide intermediate and 'dangling' images as well as stopped containers.

The Docker Images view lists all images in the Docker host selected in the Docker Explorer view. This view allows user to manage images, including:

A wizard lets the user input all the arguments to create a new container from an image. When the container is started, all the logs can be streamed into the Eclipse Console:

The Docker Containers view lets the user manage her containers. The view toolbar provides commands to start, stop, pause, unpause, display the logs and kill containers.

This view also provides a filter to show/hide stopped containers. Users can also attach an Eclipse console to a running Docker container to follow the logs and use the STDIN to interact with it.

We also integrate with the Eclipse Properties view to provide users with info and 'inspect' data about a selected container or image.

Roland Grunberg and Jeff Johnston from Red Hat started this project and are currently in the process of getting the code accepted to Eclipse.org as part of the Linux Tools project (even if the tooling also runs on other platforms), which explains why the code has not been made public yet.

Taking about code, we rely on the open source Docker client developed by Spotify to handle the low-level communication with the Docker daemons and I should thank the Spotify developers who maintain this library. They’ve been very kind to quickly review and merge the pull requests that we’ve submitted and it’s been a pleasure to contribute to their project. Open source collaboration FTW :-)

There is still some work and the screenshots showed above may still evolve as we add more features, but we hope that this blog entry will give you a taste of what’s coming soon in Eclipse with regards to Docker tooling.

While the code will be hosted in Linux Tools project at Eclipse.org, we intend to also ship it as part of JBoss Developer Studio 9 and JBoss Tools 4.3 later this year.

We also created a JIRA component to track this work-in-progress in the scope of JBoss Tools, including some issues with mockups.

Beyond this basic Docker tooling we are looking at integrating launching servers and even native CDT builds on docker containers, but this will be the subject of future posts on this blog ;-)

As usual, feel free to provide us with feedback on our forum, on JIRA or on IRC. Questions, comments and suggestions are always welcome!

Stay tuned!

/Xavier
@xcoulon

Since the default jboss/wildfly Docker configuration doesn’t expose the management port by default, we’ll need to customize it, and this means writing your very first Dockerfile. Our goals here are to add a management user to the Dockerfile, and also to expose the management ports when running the container.

First, you’ll want to make a folder on your filesystem that you can play around in. I’ll name mine docker_jbds_wf_mgmt - Inside this folder, we’ll make a new file named Dockerfile and give it the following content:

You can see that we’re extending the original jboss/wildfly container. In the above RUN command, we’re also adding a management user. Feel free to customize the password as you wish.

Finally, we’re making sure that when the Docker container runs standalone.sh, it is also making sure to bind the management port to all possible hosts, helping to expose it for use.

When creating the server remember to set the host to be dockerhost ( at least on OSX and Windows ) as shown above.

Since we’ve configured the server to be remote, and for communication with the server to be handled over the management port, we mark it as Remote and controlled by Management Operations in the second page of the New Server wizard. We also don’t require a runtime here, though we may need one later when creating a functional web project with classes. For now, we won’t create one. You’ll also note that we have marked that the Server lifecycle is externally managed, which means we won’t be starting or stopping the server via JBoss Tools, since you’ll be controlling that via Docker on your own.

On the next page, you’ll note that our remote runtime details are optional. Since the server is configured only for management operations, we have no real need to know where the filesystem is located or how to access it. We can safely ignore this page and just proceed through it.

Now, your server is created, but we still need to set the management credentials. First, double-click your Server in the Servers View to open the Server Editor. Then, set your credentials as you did in your Dockerfile as shown below. You’ll note that some default values are already there, and so you’ll need to delete them and set your own values.

In this example, we can create a very simple web project by browsing to File → New → Dynamic Web Project, Once the web project is created, we can create a simple index.html in the WebContent folder.

In this second example, we’ve seen how to install and configure a Wildfly Docker image customized for management operations in JBoss Tools.

To summarize, here are the steps needed:

As you hopefully noted, this kind of setup is much more straightforward (no messing with paths); unfortunately it does have a downside since all publishes are full publishes over the management API. Because of this, incremental updates will not work in this case.

In a future example, I hope that we’ll see how to create an image customized for SSH access, which will allow starting and stopping the server and support incremental updates.

Rob Stryker

Docker’s installation method differs based on your platform. You’ll want to review Docker’s Installation guides for your respective platforms.

To make things unified across the various platform, we recommend you go and map dockerhost to the ip of where your docker instance is running.

By default on Linux that will be 127.0.0.1, so you would add the following line to your /etc/hosts file:

But on OSX and Windows it will be a unique IP you can get by running boot2docker ip (i.e. 192.168.59.122). In that case the following should be added:

From now on you can use dockerhost in all your applications and get to it no matter what OS you are running on.

Wildfly has published their docker images for public consumption. You can browse them at the docker registry, or go to http://www.jboss.org/docker/ for more information.

These images are JBoss' standard Docker images and they do not expose more features than just the bare minimum for production and reuse. This first blog will show how to use them as-is, but going forward we will show how to configure them to be a bit more useful for development use cases.

To make sure your docker installation has worked, and that Wildfly can start without any errors, you can do the following:

This command will run the Docker image for jboss/wildfly in its default state, no customizations and map port 8080 on your dockerhost to 8080 of the running jboss/wildfly container.

Once this is run, the command will not only start up your container, but also launch the server in standalone mode, and connect a terminal to it so you can see the output.

You should also now be able to see WildFly default startup page on http://dockerhost:8080.

Assuming you see the console output, and the server runs with no errors and you can access the welcome browser via dockerhost then you’re set up and ready for the next step.

To terminate the container, you can simply press Ctrl+C. If, for some reason, your image has frozen, and Ctrl+C isn’t working, you can also run the following commands to kill it forcefully.

First list running containers:

Here I only have one container running; you might have more. But to kill any container, you execute docker kill f70149043400, replacing the given hash with your value from CONTAINER ID column.

Since the Docker image in this example does not have SSH enabled, and the Wildfly server is not exposing the Management port, we will need to configure JBoss Tools to use custom filesystem deployments. The way to do this is to map in a local folder from our host into our container.

And since we start Wildfly via the Docker image, on the command-line. we’ll want to configure our Server Adapter in JBoss Tools to be an externally managed server, so it will not manage the start nor stop of the server.

The default docker image is restricted by default. This means it does not have the Management port exposed, nor JMX nor file system access via SSH.

All this means that currently you have to go through some setup to use them from existing tools, but luckily we are doing two things:

In this first example, we’ve seen how to install and configure the default Wildfly Docker images.

To summarize, here are the steps needed:

In future examples, we’ll see how to extend those images for Management or SSH/SCP usecases.

Rob Stryker