How To Change the Ports on Your Crafter CMS Installation

One of the most common questions I get from developers is:  “When I download Crafter CMS it runs on port 8080.  How do I change that?”  They are not simply looking to put Crafter on port 80 or 443.  They want to move it to port 9080 or some other port because they are already running something on port 8080.

To make things easy, let’s look at a standard development installation — which consists of the following microservices:  Crafter Studio, Crafter Engine, Crafter Search, Solr and Crafter Deployer.

In the diagrams above you will note the black arrows between components.  These are HTTP connection to (typically) localhost and the port specified on the target component.    Let’s review each of these connections:

A. Developer/consumer goes to Crafter Studio application (/studio).  Crafter Studio IFrames Crafter Engine rendering.
B. Crafter Studio queries Crafter Search when users do a search inside the CMS
C. When rendering Crafter Engine can leverage Crafter Search to perform content queries and searches.
D. Crafter Search applies platform-specific business rules and makes query requests to Solr via connection D
E. When content, code or configuration is saved via Crafter Studio or directly via Git it is picked up by the preview deployer and published to Crafter Search.  Crafter search performs inserts updates and deletes on Solr via connection D
F. 
Crafter Studio maintains/caches project/user and operational metadata (workflow state, dependencies) about content locally in an embedded MariaDB.

Configuration for Tomcat ports:

  • Impact: Ports for Crafter Studio, Crafter Engine, and Crafter Search
  • Location: INSTALL_DIR/bin/apache-tomcat/conf/server.xml
  • Configured ports: There are several ports listed in this XML file.
    • 8005 (shutdown port),
    • 8080 (HTTP connector)
    • 8443 (HTTPS connector)
    • 8009 (AJP connector)
  • INSTALL_DIR/bin/crafter-setenv.sh / crafter.bat
    • Linux: export TOMCAT_HTTP_PORT=8080
    • Windows: SET TOMCAT_HTTP_PORT=8080

Once you change the Tomcat ports you must update the configuration for the communication between microservices to Crafter Search:

  • Impact: Crafter Studio Connections
  • Location: INSTALL_DIR/bin/apache-tomcat/shared/classes/crafter/studio/extension/studio-config-override.yaml
  • Configured Ports:  There are several ports to update when Tomcat’s connector ports are changed:
    • studio.preview.engineUrl
    • studio.preview.search.createUrl
    • studio.preview.search.deleteUrl
  • Impact: Crafter Engine
  • Location: INSTALL_DIR/bin/apache-tomcat/shared/classes/crafter/engine/extension/server-config.properties
  • Default Ports:  Update the crafter search port
    • crafter.engine.search.server.url
  • Impact: Crafter Deployer
  • Location: INSTALL_DIR/bin/deployer/config/classes/crafter/engine/extension/base-target.yaml
  • Default Ports:  Update the crafter search port
    • target/search/serverUrl

Configuration for Deployer ports:

  • Impact: Configures the ports for the deployer, impacts Studio
  • Location: INSTALL_DIR/bin/deployer/config/application.yaml
  • Configured Portsport
  • INSTALL_DIR/bin/crafter-setenv.sh / crafter.bat
    • Linux: export SET DEPLOYER_PORT=9191
    • Windows: export DEPLOYER_PORT=9191

Once you change the Deployers ports you must update the configuration for the communication between Crafter Studio and the deployer

  • Impact: Crafter Studio’s communication with deployer
  • Location: INSTALL_DIR/bin/apache-tomcat/shared/classes/crafter/studio/extension/studio-config-override.yaml
  • Configured Ports:  There are several ports to update when the deployer ports are changed:
    • studio.preview.defaultPreviewDeployerUrl
    • studio.preview.createTargetUrl
    • studio.preview.deleteTargetUrl

Configuration for Solr ports:

  • Impact: Crafter Search’s communication with Solr
  • Location: INSTALL_DIR/bin/crafter-setenv.sh / crafter.bat
  • Configured Ports:
    • Linux: export SOLR_PORT=8694
    • Windows: SET SOLR_PORT=8694
  • Impact: Crafter Search’s communication with Solr
  • Location:INSTALL_DIR/bin/apache-tomcat/shared/classes/crafter/studio/extension/server-config.properties
  • Configured Ports:
    • crafter.search.solr.server.url

Five Reasons Why You Should Use a Git-based CMS (Part 5 of 5)

In our previous posts we looked at Crafter CMS and its Git-based versioning (part 1), distributed repository (part 2), dug in to Git’s underlying mechanics to see how it benefits deployment (part 3) and we looked at how the support for branching (part 4) can help your organization dramatically speed up development and deployment activities. In this post, we’re going to wrap the series up with one final reason.

There are so many advantages to the way that we’ve leveraged Git; It’s hard to pick just 5 things to talk about. Because I’ve arrived at our last reason, #5, I want to use this item to speak to something non-technical: familiarity.

Reason #5: Familiarity

Throughout this series, you have heard me talk about a “Git-based” CMS.  That’s intentional and I want to elaborate on why that’s important.  The entire series isn’t just about a better mousetrap.  We’ve tried to take a hard look at the kind of problems that remain in the CMS space and the needs that modern organizations have in terms of innovation at a competitive level with respect to ease, speed and scale of continuous delivery.  It turns out that, yeah, some of the biggest bottlenecks go all the way down to the core of today’s CMS platform: They way we store and manage content and code.

The features I spoke to in this series are the first steps in truly making a real and major difference. What we’re saying is, we need a repository with a specification that enables these kinds of capabilities.  Developers and DevOps should not have to dance around the technology to get their jobs done.  That said, the functional specifications of features and how you implement them are different things. We could have focused on a system with “Git-like” rather than “Git-based” functionality. We chose to do the latter. We did that on purpose.

Leveraging Git rather than re-inventing it has nothing to do with code-reuse or ease of implementation. If you look around, you will find a number of projects that enable non-technical content editing and publishing (basic CMS functionality) for statically generated static websites that leverage Git.  Developers and DevOps familiar with Git, already recognize many of the benefits of leveraging Git for these kinds of needs.  However, implementing a full enterprise-class CMS designed to support modern, dynamic and personalized multi-channel experiences isn’t as simple as sticking Git under your CMS. The full range of WCM authoring, development and DevOps use cases are much different and more complex than what you see with simple editing and publishing of statically generated websites and standard source code management.  There are a lot of decisions to make and problems to solve.  A Git-based implementation is important for a much bigger reason another reason:

Familiarity matters. Familiarity covers both adoption and integration. Git is used all over the world. It’s proven. Moreover, developers and operations teams know how to use it. A Git based CMS is part of the broader Git ecosystem — which means your existing Git-friendly toolchain natively works with the CMS.

“Git-like” is not enough. Its got to be Git-based. Familiarity matters.

Conclusion

Crafting great digital customer experience is a complex, multi-step, multi-environment and multi-disciplinary practice. Today, a CMS must be as good for development and operations/process as it is for the content authors that are traditionally thought of as the primary users.  Today’s contemporary CMS platforms still sit on a basic architecture that was designed over 20 years ago when needs were different.  To meet today’s challenges a new kind of CMS is required with a new architecture that starts at the root of the platform, the repository.  Today’s needs call for a distributed repository that supports branching, advanced content/code flow scenarios and a versioning model that is multi-file.  These are Git-like features.   While the functional specification of a modern CMS repository is “Git-like” a solution that is “Git-based” leverages the power and track record of the worlds most popular source code management platform and plugs into a vast ecosystem of developers and DevOps in a way that no other solution can. 

Crafter CMS is an open source CMS project and the world’s first enterprise-class CMS based on Git. Crafter CMS is on a mission to bring content authors, developers, and operations teams together in a single platform that makes innovation easy, fast and fun.

Check out the other articles in this series: