The very idea of having a pre-configured environment in an isolated container attracted leading technology companies and millions of users worldwide. Yet, the abovementioned approaches still require a user to download software and images, as well as administer desktop. We at Codenvy went a little bit further. How about clicking one button and finding yourself in a pre-configured developer environment, having IDE with a rich set of editing tools and project sources at your fingertips? How about developing locally but building and running your projects in the cloud? Allright, first things first.
Connect Your Desktop to the Cloud
Codenvy has released its CLI tool that makes it possible to manage a remote Codenvy workspace from your desktop. First off, this is an ability to trigger remote build and run processes. You can use a cheap laptop to build and run a complex Java project that requires JDK 7, Maven and Mongo, access build and run logs or check out a running application. Every service in a Codenvy workspace is a RESTful service, exposed to be used ‘from outside’. The CLI calls particular API methods to invoke particular processes in the cloud. In a nutshell, you may not even open your remote Codenvy workspace to be using a cloud IDE. Enjoy your favorite local IDE and consume cloud resources.
You may also want to sync your projects across web based and local clients. In simple words, it is possible to work on projects offline and then push changes back to a remote Codenvy workspace, or vice versa pull changes locally, if they were made in the cloud. This makes use of Codenvy with desktop IDEs pretty convenient. The general workflow may look like:
pull a project > make changes in a local IDE > push changes back to the cloud > trigger a remote build or run
Use cloud WITH your desktop, not INSTEAD of it. If you are an Eclipse fan, you may want to look at Codenvy Eclipse Plugin .
Any Environment. Any Language
Well, almost. Anything that can be installed and run on Linux, can be installed and run in Codenvy. Docker gives us this power. Codenvy offers 20+ pre-built environments that are ready to be used (moreover, all base images are always in Docker cache, so you don’t need to wait for the base image to pull). Yes, the true power of having a Codenvy workspace is an ability to build your own Docker image, i.e. your own custom environment without the need to install Docker. It is already there for you. A user can build own custom recipe, or several Dockerfiles, if necessary. Run menu options make it possible to choose runtime to load. Building a Dockerfile in Codenvy does not differ from building a Dockerfile locally - same instructions, same rules, same output. There are a few Codenvy specific features like injecting project sources into the image. Here’s an example of creating a Grails environment based on an image with JDK7 pre-installed:
FROM codenvy/jdk7 # download Grails distribution, unzip it to /home/user/$GRAILS_HOME RUN wget -q -P /home/user/ http://dist.springframework.org.s3.amazonaws.com/release/GRAILS/grails-2.4.4.zip && \ unzip -q /home/user/grails-2.4.4.zip -d /home/user/ && rm -rf /home/user/grails-2.4.4.zip # set env variables and export them to .bashrc ENV GRAILS_HOME /home/user/grails-2.4.4 RUN echo 'export GRAILS_HOME=$GRAILS_HOME' >> /home/user/.bashrc ENV PATH $GRAILS_HOME/bin:$PATH RUN echo "export PATH=$PATH" >> /home/user/.bashrc # add your application sources to a Docker image RUN mkdir /home/user/app ADD $app$ /home/user/app/
That’s it. Having added add sources, you can execute grails commands, package your app and deploy artifacts with a servlet container of choice (you may download Tomcat or use one of our base images with most popular servlet containers pre installed). It is that simple. Of course, you will need to spend more time to build a more complex environment, and ideally, when you are done, you build an image locally, push it to Docker Hub and use in Codenvy as a base image, so that the resulting Dockerfile consists of just 3 instructions: FROM, ADD and CMD (in fact, you can specify CMD in the base image and override it in your Dockerfile if necessary).
This is one way to build a custom environment - to use Codenvy base images and install things on top of them. This approach works well if you want to have an environment that you are an expert in, since it is you who has built it up. Otherwise, you may just head to DockerHub, find a good image there (spend some time picking the best one), and use it as a base image in your custom recipe. Luckily, there are plenty of official images that are lightweight and not cluttered with unnecessary software and tools. You can create several recipes for the same application, for instance one for build and run, and the other one for PaaS deploy. Yes, custom runtime can serve as a deployment environment for the application. All you have to do is to install CLI or SDK of a chosen PaaS provider and deploy the app with CLI commands.
Docker made Codenvy runners flexible and removed all restrictions related to the nature and ‘contents’ of runners. Missing PHP module? No problem, install it. Missing Ruby gem in a default environment? Add it yourself! It is your project and your environment. So, each time a user hits Run button, a Docker script is executed. It is just a matter of what Dockerfile is used - the Codenvy one or your own.
Sharing Developer Environments
We won’t make a big splash with just this headline. The goal of Docker and Vagrant+VirtualBox is to make sharing developer environments easy. You share an image or an image and Vagrantfile, people download these resources, run a few commands and they are in.
Remember, we promised to elaborate on sharing and consuming developer environment in one click? That’s not just a marketing bait. Imagine, you have finished building custom runtime for your Grails project, and you want other people to use it. Inviting people to your workspace isn't a solution here, especially if you know none of them personally. Say, you want to share it with your blog audience. There’s a mechanism of creating project clones in Codenvy, that we call Factories. Your project, along with its custom environments (custom Dockerfiles) and settings is encoded onto a short URL that you can share with others. It can be just the URL or a nice button, the default one or with your own logo. The most interesting part is the moment when another user clicks this URL. Here’s such a button. Click it, while I’ll explain what happens behind the scenes below.
A series of REST API methods is invoked. The system gets a request to create a temporary workspace and clone a project into that workspace. As said above, project is cloned with all its metadata and custom environments. In the end, you get a copy of the source project with identical settings and environments. Source file of such a project can be edited. The project can be built and run. Users can play with environments as well, i.e. edit existing Dockerfiles or create own. The original project and workspace remain unimpacted, while a temporary workspace is destroyed in a few hours. A user can save the project into his persistent Codenvy account if any, or register and persist the project. Benefits? Well, instead of writing long how-tos and tutorials on ‘how to try out a particular framework’ you publish such a Factory button. All your users need is a browser. No downloads. No installs. No setting up environment paranoia.
One Project. Complex Environment. Simple Solution
For example, pre-reqs for the abovementioned PetClinic project would not be numerous, but still a user needs to have JDK, Gradle and Eclipse (or any other IDE) installed. Having clicked the Factory button, a user enjoys such an environment in ~10 seconds, depending on the source project size. What about more complex projects? What if 10s of tools and software need to be installed? We have recently ran into https://github.com/zk/clojuredocs project on GitHub, which hosts source code and run scripts for http://clojuredocs.org/. To run this project locally, you will need to install quite a number of things - Leiningen, MongoDB, Less and Foreman. Note that Less is installed through npm, while Foreman is a Ruby gem. Isn’t it an overkill just to try out a new technology and/or project? How much time do you need to install all those things and actually run the project? It should take ~1hr, provided that you know how to configure MongoDB and install Leiningen without peeping too often into their docs. Click this button to find yourself in an environment specifically tailored for this particular project. Run the project, to package the app run it on 5000 port:
Each time a Factory button is clicked, a new temporary workspace is created. Every user will work on the project in isolation. The project and the environment stay the same. There are numerous ways to configure a Factory, imposing access and behavioral restrictions, specifying post-loading actions like opening README file after a temporary workspace is created, to introduce a project and guide users through build and run processes, default runtime environments (there can be more than one Docker scripts associated with the project) or a recommended amount of RAM the project requires. It does matter if you want to build an Android app with Gradle and run it in an emulator:
or run and deploy Java GAE project using GAE SDK:
or maybe play with MongoDB:
- all you need is a browser. Hard work is done in the cloud. Experimenting with new technologies and projects is easier than ever.