Over the years I have set up countless development environments. And to help ease onboarding for new developers, I have leveraged several technologies. Like Chef, Vagrant, VirtualBox, and most recently Docker. Each of these had their pros and cons. But the biggest issues I've had have been distribution and support. For example, how to get a Docker environment to a developer who may be a JavaScript guru. But knows very little about Docker.
Then I came across dev containers. While getting ready to get the Azure Developer and Administrator Associate certifications. It was very useful as I worked through the labs and I had to switch between environments and languages. So I made it a point to come back around and setup a dev container for AEM developers.
Install Visual Studio Code & Docker
First you will need a supporting IDE. Visual Studio code is one of the supporting editors. And the one I will be using. Along with the Dev Containers extension. You will also need Docker. The installation of these is straight forward and documented on the VSCode site.
Dev Container Templates & Features
I created this template ghcr.io/juan-ayala/devcontainer-templates/aem. To create the devcontainer.json specific to an AEM environment. It will use a base docker image. And layer in the required tools via dev container features. I chose to build the solution using a generic base image. Because it reduces the complexity associated with building a custom image. And layer-in features instead. Because they increase flexibility by allowing for an à la carte approach.
The template references a feature created by me, ghcr.io/juan-ayala/devcontainer-features/aem-sdk. It will install a set of shell scripts. They will help in setting up and running the AEM author, publisher and dispatcher. You will need to provide the AEM SDK and place it under the .devcontainer directory. It is only available from Adobe's Software Distribution site.
AEM WKND Guides in a Dev Container
If you are an AEM pro, you know adobe/aem-guides-wknd. Lets pull this repo in VSCode, and apply my AEM dev container template. Use the Dev Containers: Clone Repository in Container Volume... command. This will pull the repository into a Docker volume. Once the dev container is up and running, access the integrated terminal. This is a terminal into the container. If you run my custom command start-aem author you will find you need to download the AEM SDK first.
Alternatively, if you have already pulled the repo to your local storage, you can use the Dev Containers: Add Dev Container Configuration Files... command. Either way, when prompted, use the ghcr.io/juan-ayala/devcontainer-templates/aem template.
Download the AEM SDK
Log on to Software Distribution and download the AEM SDK. Once downloaded it, drag it into VSCode under the .devcontainer folder.
Start the AEM Services
Once the SDK is in place, you can start the AEM services. Open the integrated terminal. And use the start-aem <service> command installed by the aem-sdk feature.
Build & Deploy The Project
The dev container contains all the tools we need. And the aem-sdk feature has setup the AEM services we need. Now build and deploy the project.
Replicate The Build
If you wanted to develop on author only, then you can stop here. But if you want to see the setup through to the dispatcher, you will need to deploy the build on the publish service. There are several ways to do this, but I am going to replicate the all content package from the author. For this I have created a script called enable-replication.sh. This simulates the Sling Content Distribution on a local environment.
View The Site Through the Dispatcher
Finally we come to the Apache service. Running the dispatcher module. The custom start-aem dispatcher command will unpack and install the dispatcher tools. And run the docker_run.sh. But if you wish to use one of the other scripts provided by the SDK, they will be available in the PATH.
Conclusion
Setting up Maven, Java and the SDK, and troubleshooting anything that can go wrong. This has become second nature to me. But it takes time.
A dev container template and feature are easy to distribute. And it can get checked into source control. This helps to onboard new developers. And provides a quick way to switch between versions and tool sets. Going forward this will be how I kick off new projects. And I will be adding features as soon as I find I need them.
Comments