I’m working on an app that’s actually two apps, located at /{serverroot}/app1/ and /app2/. I’ve just been using a single local URL with those app-specific directories after, but other folks here are running standalone Lucee on Apache, with separate host names for each app, and I’ve been asked to do that too.
I’m aware of the web.host setting in server.json, but I don’t see how to use 2 host names, or how to point them at different directories.
Is that possible?
Thanks.
That’s not how CommandBox works. It was designed in the container mentality, so you start up a server (JVM container) for each site you want. In other words, each CommandBox server is a separate JVM process with a single web root. If you want two websites in two different webroot, start two CommandBox instances.
Since CommandBox servers are easy to start/stop and manage, they can be started with small heaps that have low overhead.
Add a second IP address to that machine and bind each site to it’s own ip. Then have your DNS point to each IP as needed. I have an AWS instance that has multiple IP addresses, each has a commandbox instance bound to it and each has their own url.
Thanks for chiming in Dan. That is the recommended approach for sites you need accessible outside of the machine if you don’t want them on non-standard ports or don’t have an IIS/Apache layer to proxy on port 80. However, if Dave’s only need is for local development and he only needs to hit the sites locally, then he can use the “commandbox-hostupdater” module to run several sites on local host and all bound to port 80.
Thanks for your help guys, I’m getting back to this finally.
Big picture: This is an app that interacts with other sites. That main app is running fine locally on CommandBox. The problem is that the source tree contains code for two test sites intended as test targets; they aren’t part of the app itself.
The main app needs to be able to hit each of these test sites at different absolute URLs. Access from off the box isn’t necessary, so host file entries are fine. Non-standard ports are ok. (The main CommandBox instance, i.e., the main app, is already on one.)
If the source for the test sites wasn’t inside the main app tree, running separate CommandBox instances would be the way to go. As it is though, I don’t see a way to tell the main CommandBox instance that these two dirs inside the root CommandBox is serving should NOT be served by it, but instead should be handled by two other instances. In other words, I effectively need atwo separate servers running code that’s inside a different one.
I totally understand that this is very much an outside edge case, and I’m not suggesting that anything about CommandBox should be different. I’m just trying to figure out how to get this odd configuration running somehow, so I don’t have to abandon CommandBox as my dev environment for this app, and move to discrete Lucee instances running on Apache, which is what everyone else is doing.
Is it possible to run CommandBox instances behind Apache? Roughly how, and is that documented somewhere?
Big big picture, CommandBox has a bunch of advantages as a dev environment, so I’ve been using it myself, hoping to eventually bring it forward to everyone else as a good way to go. But along the way, this wrinkle appeared in how things are configured for this app, and I’m pretty much at a fork in the road, get it working or bail.
Thanks again for any ideas,
Dave
I don’t see any reason why you can’t start a server that points to a subdirectory of a folder that’s being used as the web root of another server. Sure, it’s odd and you should probably rearrange your repo but I don’t see why that wouldn’t work. CommandBox doesn’t DO anything to the web root like place file locks or anything on it. It’s just simply the folder that the web root points to. Heck, you could have two servers pointing to the exact same folder as their web root and CommandBox wouldn’t care. (I do this all the time to test the same code in multiple CF engines)
So if you need three servers running, then simply run them and point them to whatever folder you want them each to use as their web root. Forget about the fact that some of those folders may be contained within another web root.
I don’t see a way to tell the main CommandBox instance that these two dirs inside the root CommandBox is serving should NOT be served by it,
Why even worry about blocking stuff? If there’s a folder of code that you don’t want/need to hit in your browser via the primary CommandBox server, then just don’t navigate to that URL! Why does it need to be any more complicated than that? This is all local for testing it sounds like so I don’t think security is coming into play.
Recently saw CommandBox in action at ColdFusion Summit 2018 in Vegas. Very impressed with it and thought it might be a piece of technology that my growing small business could utilize to get new devs up to speed. Trying to evaluate the technology I ran into an issue.
My current monolithic software is a beast that needs multiple sub domains. Fortunately each piece has it’s own folder it runs off of. For example our api is housed at api.domain.com in the api folder and our management area is at manager.domain.com in the manager folder. If I’m reading this right. I’d need to spin up a CommandBox server for each subdomain we have in our application?
That’s correct, one server instance for each webroot. You can get clever and do stuff with URL rewrites that would map each subdomain to a subfolder but the out-of-the-box behavior follows the containerized/microservice mindset.
Hey Dave - I am writing to encourage you to be persistent in getting CommandBox to work, so you can get your colleagues out of their old world, monolithic, legacy installer mentality. It just doesn’t make sense in 2018 to use an installer for Adobe ColdFusion or Lucee; that is such a waste of time. Any manager that pushes you the opposite way of CommandBox, is doing you a disservice.
The CFConfig module will pull all of the settings out of your legacy installed ColdFusion/Lucee Administrator and save them to a CFConfig.json. That gets auto-loaded into your CommandBox server when you start it, after adding the cfconfig path to your server.json. If you have ever used .CAR files (ColdFusion ARchive), CFConfig is WAY better, and faster. Login to your CF Admin, change the settings for development, and export them to a dev copy of CFConfig. I have Dev copies, QA copies, and Production copies for every site. I put my server.json and cfconfig files in a Git repo that my development team shares, so we’re all on the same page, using the same settings, with every site for local development. We still have legacy databases per environment. We aren’t using Docker containers yet either.
I’m using CommandBox in Production too, with SSL, URL Rewrites, IIS equivalent Virtual Directories and Windows Services. I just wanted you to know that all of that is possible with CommandBox, and it doesn’t require IIS, Apache, NGINX, or Brad to set it up for you, LOL.
Keep at it and ask questions. I promise you it is worth the effort.
Jim Pickering