[Looking for Charlie's main web site?]

Pulling Adobe Docker CF images, for now via Amazon ECR, and soon via Dockerhub

Here's some good news for those interested in using the Adobe CF Docker images: it turns out you are NOT required to do the clunky "download/docker load" dance that had been announced in this Adobe blog post on Apr 30, the day before the announced closure date of the previous registry they used, Bintray. There are three other alternatives to do a traditional docker pull, which I didn't know about and I suspect others may not either:
  • First, you can now pull images from Amazon Elastic Container Registry (ECR), including both the CF2021 image and 2018, as well as the add-on and PMT images for CF2021. These are official Adobe images, to be clear. A simple example--that works today--and will give you the CF2021 update 1 image is the following:
    docker pull public.ecr.aws/adobe/coldfusion:latest
  • Second, soon you will be able to download them from DockerHub as well ("the way it's supposed to be", some would say). No date set for that, but indications are that it will be "very soon", according to Adobe. Update: As of June 22, 2021 Adobe has now created a repo on Dockerhub. For now, there are no images there yet, as of a check on July 6, 2021. But keep an eye on it, as it seems they will appear soon.
  • Update: As of a check July 6. 2021, the bintray repo is indeed no longer available. That said, you can still use the images you may have pulled, even using the eaps.bintray.com/coldfusion repo name prefix before the image names. It's only pull requests that will fail. Going forward, use the other options above. Here's what I had written back on June 17: Finally, despite what the Adobe and Bintray sites said about the May 1 "closure" of bintray, saying that images would be inaccessible after that date, Docker images at Bintray DO remain available for now. This includes CF2021 update 1, CF2018 update 11, CF2016 update 17, and more, so existing docker pulls against those do still work, at least as I write today, June 17 2021

Both the first two were mentioned in a comment yesterday on the Adobe CF forums. And I discovered how the continued Bintray image availability while writing up this post to share the news about those other two!

For more information, including additional background on this transition, more on using the ECR images, and still more links to resources discussing these things, including docs on using the Adobe CF images that many never seem to notice, read on. (I also did an "in brief" version of this post on the Adobe CF portal, where I share the "least you need to know" above. Again, for the rest which should be interesting stuff for many, read on.)

[....Continue Reading....]

Thanks Charlie for being more patient, polite and concise than I am!!! :)

Your todo list is spot on - hopefully Adobe will get these addressed soon.
# Posted By Jim | 6/18/21 8:33 AM
Me...concise? Erm...ok, thanks. :-)

But seriously, thank YOU Jim for pressing in that post, and thanks of course to Kishore for jumping in. I've noticed more participation by Adobe in the forums in recent weeks. Here's hoping that's a concerted effort and a trend that continues.
# Posted By Charlie Arehart | 6/18/21 8:38 AM
Hi, Charlie. I'm a "long time listener, first time caller". I've been following your CF content for years, probably decades at this point, and I would like to say "thank-you" for your thorough, thoughtful and expert commentary on the CF platform. I can't tell you how many times one of your posts has resolved difficult problems for me.

Now my question. And this is indeed a Noob question. I am new to Docker containers and I understand the fundamentals for the most part, though the interaction between various running containers still remains a bit confusing to me. I'm sure I will be able to resolve this with a deeper dive into compose files. But, I have not seen mentioned anywhere how we would incorporate IIS, or more likely Apache's httpd web server, into a Dockerized CF environment. I intend to use Docker for local development on my Mac (I'm using Parallels VMs quite effectively right now) so I'm trying to match the production environment to which I deploy to the highest degree possible. Can you suggest a good reference that I can peruse?

Thanks again for all you do for the CF community!

M. McConnell

PS: I love the fact that you're still using BlogCFC! If it ain't broke, don't fix it.
# Posted By Michael McConnell | 6/19/21 10:55 AM
Nevermind! I found this after doing a little more poking around on your site:
I'll take a look and see if I can find my answers there.
# Posted By Michael McConnell | 6/19/21 11:17 AM
Hi, Michael. First, thanks for the kind regards, and glad to have helped (all these years).

Second, as for your interest in how best to run these CF Docker images with Apache, well, that's going to prove challenging. Not impossible, but challenging. And I don't think you'll find (or will have had much success seeking) info on that.

Let me explain why. Settle in. I not only talk about why, but propose alternatives.

For one thing, you will learn (as you may already know, being familiar with Compose) that the design intention is that one would not run any single container that contains something like both CF and Apache.

You will find some people over the years who have tried to do it (with CF, and indeed with other things), and again it can be made to work, but it's not optimal and not the cloud-native way (where instead there should be only one main process per container).

So indeed, the general recommendation is for each such process to be its own container (image), so one for CF and one for Apache, and yep you could stitch those together with Compose (or Swarm or Kubernetes, etc.)

But then the next issue you will hit (and the more difficult one to overcome) is that if you mean you hope to run your local env JUST like production is that you will likely in prod be using CF's web server connector tool (wsconfig) to enable the AJP connector in Tomcat.

That tool when run on a single machine running both CF and Apache (or CF and IIS) can easily configure "both sides" of the connection: some settings enabled in the Apache (or IIS) configuration files, which then point to some "CF" (really Tomcat) configuration files on the CF side.

The problem when using containers is that you do NOT have both CF and the web server "in the same machine". Well, you may, but the problem is that the wsconfig tool was designed to be run "inside the CF machine"...and that too is antithetical to containerized deployment--where instead you are expected never to have to "go into" the container and run such tools.

Now, can the wsconfig tool be run via the command line? Absolutely. But that's not the only problem. Again, it would want to try to configure the web server side of the picture...but it has no access to that. (Sure, one could hack it with volumes, perhaps, but things could get ugly and brittle.)

Someone may point out how "this is really no different from what CF has long called 'distributed coldfusion'", where CF and the web server are on different machines. And they might propose that one could follow the steps offered in docs for that, to configure all this manually, and indeed you can. But there would be a fair bit of work to get it to work. Still, it can be done.

All that can seem dissatisfying, but in fact there are other options you can and perhaps should consider. It's just that they are NOT options that will allow you to configure the setup here to be "match the production environment", and they also have not been discussed a lot in the world of CFML containers (and definitely not from Adobe).

So what are those options?

Well, they start with recognizing that CF does in fact already have its own web server. We don't "really" need to "add one". It's the same one by which we are expected to use to access the CF Admin (configured by default to be enabled since CF2016, and before that optionally).

Now, some will recall that in the era between CF6 and CF10, we were told "the built-in web server is a development server, not meant for production". Partly that stemmed from the fact that that built-in server was the JRun web server. It was not really designed to be production-worthy. It also lacked many features that some would want in a web server. So it was indeed indicated in the CF installer (from 6-9) as "the development web server", and it was not enabled by default.

But then in CF10, as you may know, Adobe rewrote CF to run on Tomcat instead of JRun. And in the bargain, they were able to jettison that jrun web server to instead leverage (as the built-in web server) the Tomcat web server.

This is a bit confusing, because some people may hear of Tomcat users tending to always use Apache. Why would they do that, if there was a web server already built-in? Well, for one thing, the Tomcat web server is again not nearly as full-featured as Apache. For another, many folks were either already familiar with Apache or could readily find docs and resources about it.

So, what does all that have to do with CF Docker images? Well, again, I am saying that built into the CF Docker images is indeed this built-in web server. It is listening by default on port 8500 (just like a regular install of CF would), and if you expose that port 8500 from the container, you will find for instance that you can get to the CF Admin at CFIDE/administrator, just like normal.

And you may know that any code you either copy into the container's /app folder or any volume that you map to that /app folder in the container will indeed be available as if they are at the root of that web server (exposed by default as port 8500).

So, am I saying "just use that web server"? I am not.

Again, it's not very configurable. FWIW, I blogged about it back in the CF10 era:
https://www.carehart... .

But what I'm getting at is that you CAN in fact configure Apache (or other web servers) to FORWARD (or "proxy") requests to that port 8500. Then you would STILL have all the power of Apache (or other web servers), and the CF/Tomcat built-in web server would be "rather dumb", just acting as a "server of CF page content" that is passed out to the external web server, which is sent back to the user.

One may reasonably ask, "well how different is this then from how things work between Apache or IIS and CF today". It IS different. For reasons known more to time and history than to recent memory, Adobe opted to go with the Tomcat AJP protocol as the way that either Apache or IIS would talk to CF. And THAT is what the wsconfig tool configures, always.

Adobe COULD have either offered an option or just opted instead to go with a port-forwarding/proxy solution. They may even chime in here with reasons why they did not, or have not, and perhaps will not.

But again for your challenge (shared by many) of wishing to have a Docker setup "mirror production", you will be hard-pressed to do that.

Then again, if you manually configure Apache to port forward to the CF built-in web server, it's really just a couple of lines (proxypass and perhaps proxypassreverse) in the httpd.conf, which would map the incoming requests to the backend running CF at port 8500. You may also need to enable the Apache mod_proxy module (.so).

To be clear, while I am not aware of any docs showing this with CF, you can find ANY docs on using Apache port-forwarding to ANYTHING (it need not involve CF or even Docker). You could look for examples showing forwarding Apache to Tomcat (as again, it's the Tomcat web server running inside CF anyway). One example is this (which is not about Docker, but again it doesn't matter):


Or again, expanding beyond considering Tomcat, here's something talking about setting up Apache proxy forwarding to something that is NOT Tomcat (again, it doesn't really matter):

And I had mentioned it can be done with other web servers also. You can find still more of examples of doing it also with nginx, including with Docker and Docker compose. For example the "CF Swarm" guide from Sam Knowlton of inLeague shows doing it with nginx and Lucee (and its port 8080):

And one of the benefit of using a web server other than Apache is that the other may be more modern/container-oriented. nginx is (available both as open source and commercial).

Going even further, another benefit of something like that over Apache alone is that it can act as a load balancer, talking to any of many containers of the same name, listening on the same port, when those have been scaled up (whether via Docker compose/swarm or the Docker run command). And example of that (again having nothing to do with CF, but again there are many such resources on the web) is this:

And even more powerful (and more cloud native) is Traefik, an open source tool offering load balancing, proxying, and more--and again in a still more container-native way than even nginx.

I'm just trying to make the point that while most CFers are familiar with running things via Apache or IIS, the same way they have for years, it really is in your interest to expand your horizons when it comes to working with CF as a container. Trying to shoe-horn it to work with Apache will be hard enough--all the more when the CF wsconfig tool presumes only to set it up for AJP and not port forwarding.

Finally, those using IIS will wonder, "how can that work with containers?", and it's the same problem as Apache: the CF wsconfig tool presumes to find IIS and CF on the same server, or if setup like "distributed cf", where one does all the manual configuration, it still works only via AJP.

So one will wonder: can IIS be set to do such port forwarding as discussed above? And the answer is that it can...but not as it's installed by default. Instead, you need to enable the IIS "ARR" extension, Application Request Routing (https://www.iis.net/...). Here's an article on setting it up for reverse proxying (having nothing to do with Docker or CF/Tomcat):

You will find very little on using IIS ARR with CF, and less still on configuring it manually (generally needed when using things in Docker), and far less (virtually nothing) on using it with Docker in particular.

And even if you did manually configure things, another major challenge for anyone hoping to do things with IIS and CF's Docker image is that IIS would of course need to run as a Windows container, while the Adobe CF Docker image is a Linux container. It would be possible to setup Kubernetes, where each is on a different pod, and they could talk to each other, but that's WAY beyond the scope of Michael's question. :-)

And I realize that my comment here is already WAY more than he may have expected would be needed to answer his question. But as I said, there has been little discussion of all this in the CF community, and while this perhaps should have been a blog post, I'll let it stand here as a comment instead, and I welcome thoughts from you, Jim, or anyone else reading it.

Then perhaps I will re-craft it as a blog post (or series), perhaps with real examples. As is often the case, it will just be a lot of work to explain it completely. I sense that I should really just start with some example compose files that demonstrate doing the most basic implementation of these things, in the various approaches above. We shall see.

Until then, I welcome comments here. If they become too numerous, I will at least create a new blog post with the content of this comment, perhaps tweaked based on other comments to that point. I don't mind waiting to see how things go here, before committing the same info to a blog post, as I did just write this off the cuff, to reply to your question. :-)
# Posted By charlie arehart | 6/20/21 5:05 PM
Hey, Michael. How did it go with your hope to integrate a web server with the CF images? I realize that what I wrote was a LOT to take in. :-) I wanted you and other readers to understand the issue.

If/when you have time, I hope you'll update us on how you went, and I'd of course welcome hearing from others on that or related matters.
# Posted By charlie arehart | 7/13/21 11:55 AM
Copyright ©2021 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting