Coder allows you to develop using your favorite IDE and preferred language from anywhere and then deploy to any popular runtime. In this tutorial we’ll build in Java with the Spring Framework using IntelliJ and then deploy to Cloud Foundry.
The primary advantages of Coder for development and Cloud Foundry for deploymen are that you get an integrated process that minimizes start-up time, reduce dependence on specific workstations, and can increase developer productivity. All operations-related processes are automated, enabling you to focus entirely on developing and then running your applications.
Before we start, to ensure everyone has complete context, let’s define the primary components used in this process, Coder and Cloud Foundry.
Coder centralizes an organization's development initiatives by moving software development to the cloud and unlocking substantial gains in both developer velocity and enterprise security. It facilitates the creation of development environments from predefined images. The dev environments can then be accessed from anywhere, at any time, from any device. The only requirements are internet access and a web browser.
Cloud Foundry is an application platform-as-a-service that simplifies the task of deploying finished projects. It runs apps written in any programming language in containers and works on a variety of cloud service providers.
Before we proceed, let’s take a look at the steps we’ll be completing to 1) set up a Coder development environment to create your application, and then 2) deploy the application using Cloud Foundry. Note that we’ll be using the Spring Music application in this workflow to demonstrate the process.
intellij:latestimage available on Docker
Note: For the purposes of this blog post, we’re assuming that you have:
- A Coder deployment that you can use to create and work on your application
- A Cloud Foundry account that will deploy your application
As such, we’ll skip the steps required to set up a Kubernetes cluster and to install a Coder deployment into the cluster. If you need help installing Coder, please review our installation documentation.
Images are the backbone of all Coder development environments. Specifically, the image is what Coder uses to create a personalized environment. The image contains everything you need to work on the project: the appropriate version of the language, tooling, dependencies, and so on. In this post, we’re using an image that features the IntelliJ IDE, but you can create and use images that contain and use standard tool sets and other major IDEs.*
These images are Docker images available in the Hub that can be imported into the Coder platform as needed — once someone creates an image, it can be used again and again by other users, speeding up the onboarding and set up processes and enabling developers to focus on writing code.
For this project, we’ll be working with the codercom/intellij image from the Docker Hub. Coder maintains links to different Docker registries, so once you’ve linked a registry, you can import images simply by providing the repository name. You can also define the minimum resource allocation that someone might need when building an environment using this image, though you (or the developer who creates an environment using the image) can allocate more to the environment as desired:
As we previously mentioned, once someone imports an image, it becomes available for use by anyone in the same Coder organization:
Once we’ve imported the image, we’re ready to create an environment where all of our work on the project takes place:
Coder then creates the environment; when done, you’ll be redirected to an overview page for the environment, which shows you high-level information including the allocation of resources devoted to this environment, the applications that you can use (specifically the Terminal and any IDEs available to you), Dev URLs (which are URLs that allow external access to things like live previews of your projects), and more.
Notice that there are three applications available to us for use with our project in this environment: VS Code, Terminal, and IntelliJ. To get started, we can launch the terminal to clone the Spring Music repository into our environment, then switch into that directory so that we can make changes to the application.
$ git clone https://github.com/cloudfoundry-samples/spring-music.git
$ cd spring-music
Before proceeding, let’s take a look at what the sample app looks like by running it:
Now, we need a way to view the sample app that’s running. Since our development environment is running remotely on the Kubernetes cluster, we will create a Dev URL. Dev URLs are a Coder feature that allows developers to access the application they are working on. The URLs can be public, private, available to others in your organization or to anyone logged in to your instance of Coder Enterprise. This provides a great way to test the application as it is being developed.
We’ll serve our application on Port 8080 and make it so that anyone with the URL can view it.
Once we create a Dev URL, we can see it listed on the environment overview page:
The Dev URLs section of the overview page is where we can go to copy the URL so that we can share it with someone else or edit our URL (i.e., changing its port value). We can also use the provided icon to launch a browser that serves up the app at any time:
With a live preview ready, we can edit our application. Remember that we cloned the repository earlier; we can edit our application using either VS Code (which is the default editor for Coder) or we can use Coder’s multi-editor feature to use one that we’d prefer or is more appropriate to the project we’re working on. In this case, we’ll be using IntelliJ.
We can preview our changes at any time with the Dev URL/live preview functionality:
We’ll be pushing our app to Cloud Foundry, an open-source, cloud-based application platform. With Cloud Foundry, we have a platform as a service that allows us to deploy our application in just minutes without managing the underlying server setup and infrastructure management.
Before we publish our application, we’ll need to build it:
$ ./gradlew clean assemble
Once your application builds successfully, you can push to Cloud Foundry:
$ cf login -a https://api.run.pivotal.io -u [email protected]
# you’ll be prompted for your password at this point
$ cf push
Note that we can use the
cf push command because what we need to push to Cloud Foundry was included in the image we used to create the environment. Once someone creates an image that includes Cloud Foundry, others can use the image and push their apps to Cloud Foundry without additional setup. By creating development environments from a centralized repository of images, Coder saves developers hours or even days of time that would normally be required to manually set up and configure their environments and it ensures consistency across the team.
If all goes well, you’ll see output similar to the following after pushing your app to Cloud Foundry:
routes: spring-music-forgiving-puku-wn.cfapps.io last uploaded: Mon 03 Aug 17:30:30 UTC 2020 stack: cflinuxfs3 buildpacks: java type: web instances: 1/1 memory usage: 1024M start command: JAVA_OPTS="-agentpath:$PWD/.java buildpack/open_jdk_jre/bin/jvmkill-1.16.0 ... state since cpu memory disk details #0 running 2020-08-03T17:31:25Z 0.0% 215.2M of 1G 163M of 1G
Notice the routes information in the Cloud Foundry output; you can use this to access your newly published application:
We have taken our Spring Music application and very quickly moved it through the pipeline from development to production, all without having to worry about infrastructure.
Coder transforms your development environment from individually owned workstations to the cloud, allowing you to focus on writing code, not on setting up development environments. Cloud Foundry simplifies the act of deploying your app by removing the need for you to handle infrastructure-related tasks. Together, the two platforms can enable rapid, seamless application development and deployment, maximizing your engineers' velocity.
Note: Coder will add support for Spring Tool Suite 4 beginning with v1.10 (release date 2020-08-20).