[Looking for Charlie's main web site?]

Pulling Adobe Docker CF images, via Dockerhub or Amazon ECR

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, you can now also get Adobe CF images from Dockerhub, at least as of Sept 2021. Update: When I first wrote this in June, there was still no dockerhub repo. That changed in July when the CF Dockerhub repo was created, and now as of this update on 9/13/2021, you can get the 2021 update 1 image using:
    docker pull adobecoldfusion/coldfusion:latest
  • 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.)

Where the buffalo roam...finding a home for the Adobe CF images

If you've been following the news of Adobe's providing Docker images (for CF2021, 2018, and 2016), you may know that there's been a bump in the road for several weeks, since the registry they first chose, JFrog Bintray, "closed" on May 1 (as JFrog had announced in Feb). The day before, Apr 30, Adobe offered a blog post explaining how they were now offering the CF images via downloadable tar.gz files which you'd have to save locally and use the "docker load" to import as an image. Ugh.

That was a really clunky response--and all the more frustrating since I and others had given Adobe advanced warning about this pending closure of Bintray, such as my blog post a month earlier, on Mar 30.

Bintray had been the Docker registry Adobe had used since 2018, when they first released the Docker images for CF2016 and 2018 (then) and later CF2021. Even then, many wondered why Adobe chose Bintray over the industry-standard Dockerhub. Still, at least pulling from Bintray would work...until May 1, 2021, as we were told (by Bintray and Adobe).

As for the offered alternative of the "download and docker load" dance, that was indeed frustrating, and besides comments in the posts above, CF community member Jim Priest was compelled to post a message in the Adobe CF forums just two days ago, asking about this very issue, and how it reflected poorly on Adobe's support for CF and the CF docker images.

The news shared yesterday, about AWS ECR now and DockerHub to come

So it was quite a surprising and compelling thing to see a a response from Kishore Balakrishnan of the CF Team who yesterday (June 16 2021) said in reply to Jim:
"We are planning on having our Docker image both on Amazon ECR and DockerHub. Docker Hub is a work in progress we should be there very soon. On ECR we have the ColdFusion container at https://gallery.ecr.aws/adobe/coldfusion/"

Wait...what?!! I checked it out, and indeed the ECR images are indeed available. That and the plans for DockerHub were indeed news I felt worth spreading and celebrating, so I started on this post (and an abbreviated post I offered on the Adobe CF portal).

And I could have left it at that, but as I looked over the info at the ECR CF repo, I wanted to add a bit more to help others who may decide to take that ball and run with it. That led to the rest of the info below....and as I was preparing that, I made the discovery about Bintray still being available....

About Bintray, no longer available

So I was just about to post this entry (and the rest below), when I thought to check one of the ECR images against one of the previous Bintray images I had...and when I did a "docker run" against one I assumed I had, I found Docker reporting that it was pulling the image down from Bintray. I was shocked.

Everything from JFrog (in the run up to May) and from Adobe indicated that May 1 was a drop-dead date. As words on their the JFrog announcement about the closure (from Feb 3) still say in a FAQ toward the bottom "On May 1, 2021, the sunset will impact all existing Bintray users. Bintray users will be blocked and will no longer be able to use the Bintray service." That certainly seemed to indicate the doors would be closed, "no more pulls".

But again, it worked today.

So I looked more closely at the Frog announcement page, and at first I noticed an "update" at the top of that that page, from Apr 27, which gave me a start: "We listened to the community and will keep JCenter as a read-only repository indefinitely.". At first, I thought this might have been indicating that they'd had a change of heart, and at least past loaded images would remain available indefinitely.

But then I noticed that was about JCenter, another service announced there as closing on May 1. But that is NOT Bintray. They are separate. Only JCenter is remaining open "indefinitely", in read-only mode, it seems.

As for why I found pulls of CF images still working from there today, I found yet another FAQ on that announcement page saying, "JFrog will begin deleting data several weeks after the official sunset date". This is indeed still in that "several weeks" window.

So again, bottom line: don't EXPECT the Bintray repo of CF images to remain available going forward, but if it helps to know they are there, enjoy. (Indeed, I am grabbing many of the past images, because it can be SO helpful to use them for demonstrating "how things worked in CF" per some given update level.)

About AWS ECR and its CF repo

So, back to the only Docker registry that Adobe is (for now) formally supporting, let's talk about that a bit more. I already shared above the docker pull command for using the CF image available via the AWS ECR.

First, how would one know that is the command to use?

Well, if you visit the page there for the CF repo, again https://gallery.ecr.aws/adobe/coldfusion/, you will see that it offers only a VERY brief description ("The official Adobe ColdFusion Server Docker Image"), and an "about" tab offering a link to the long-existing docs about the CF image (I blogged about those docs and the Adobe CF images back in Aug 2019).

But there is also a "usage" tab there, and that offers the example "docker pull" command above, and it offers a few additional commands (more on that in a moment).

Other CF-related images at the ECR repo

One thing not made clear in Kishore's brief note is that Adobe has offered not only the CF (2021) image but also these others, which is great. They each have their own "about" and "usage" tabs:

FWIW there is also not, for now, the CF Enterprise API Manager image yet (though it had existed at bintray, and which had its own docs).

Hopefully Adobe will get CF2018 update 11 posted, as well as the API Manager (and perhaps the CF2018 addons and PMT).

Hopefully Adobe will get CF2018 API Manager posted.

Learning more about using the CF Docker images, including commands, environment vars, dockerfiles, and compose files

Finally, while revisiting this whole matter of the Adobe CF images, and speaking of the ECR CF repo, I want to reiterate the importance of the CF docs that discuss using the Adobe Docker images.

First, I'd mentioned how the "usage" tab on each of ECR pages, like the one for the CF image, shows example "docker run" commands for working with the image. That said, the examples are rather terse, indeed incomplete. (None of the examples there show using the -p or -P arguments for for exposing ports, which is necessary to access the container when started that way.)

Second, recall I'd mentioned that the "about" tab on the ECR page for CF points to the Adobe docs page on using their images. Indeed, this doc page is pretty substantial and covers using all the different Adobe images, including the addons and PMT).

The doc page also covers more elaborated docker run commands, as well as info on all the environment variables supported by the CF Docker images, and even info on configuring the images via properties files (which feature was updated for new CF2021-specific aspects of configuring via json).

The docs page even shows use of the images with Docker Compose, including a compose file showing integration of CF and a MySQL image (including a dockerfile to intergrate the needed mysql jar file) as well as the CF addons image. Still another compose file shows integration of CF and PMT images.

You really don't want to miss those docs, when getting started with the Adobe CF Docker images.

That said, while the doc page was updated in May to discuss the new "download and docker load" approach to creating images, it has NOT yet been updated to mention the availability of this AWS ECR registry of CF images, nor does its examples show using them.

A gotcha to beware: Indeed, a side-effect of the last point is that both that docs page AND the "usage" tabs on the ECR pages have an unfortunate problem, at least as of today. They show sometimes use of "docker run" commands where the image name used is just "coldfusion:latest". While that will work if you have used the "download and docker load" approach (which presumes to name the image like that), if you DO proceed to get the images from ecr, then you MUST use the complete container and image name, such as "public.ecr.aws/adobe/coldfusion:latest" for the CF2021 image.

Frustrating, yes, but progress being made

So yes, all this is frustrating, this journey we have been on in recent weeks, indeed months. But it seems there is light at the end of the tunnel. I'm trying to stay focused on the positive.

Yes, it's annoying that we didn't have the CF images in dockerhub to begin with, and yes the curious "download/docker load" approach was all the more annoying.

I'd even say it's frustrating also that news of these plans for dockerhub and the availability of the ECR repos were offered only in a comment on a forum thread, rather than in an Adobe blog post. (There's been a curious vacillation there, with some info going from them to one place or the other, or both--as most recently about the coming support of the Azul JVM, here and here.)

Hey, I'm just a messenger in all this. To be clear, I have nothing to do with any of those decisions and am simply trying to help everyone.

And yes, because I know some will want to make sure it's said...you can "just skip all this and use the Ortus Commandbox Docker images for CF instead". The Ortus images are quite different from the Adobe ones, with each offering different configurable aspects. That said, folks interested in deployment of CFML via containers should be aware of both options, to choose what's best for their needs.

As is often the case, I'm simply trying to help those who ARE using the Adobe-provided means of doing things. Others can make the case for using alternatives--along with the biting commentary, sarcasm, and derision about Adobe and some of their actions.

As always, I'm just trying to help. (And I prefer not to see those sort of negative comments here. There are plenty of other places for that.)

A few things I hope Adobe can fix from all this

So as we wrap up, and in case someone at Adobe may see this and want to take responsibility to improve things, there are a few take-away's/problems/opportunities for improvement I've identified in this post:

  • Of course, please get CF into Dockerhub ASAP!
  • Please also get CF2018 update 11 into the ECR repo ASAP. That seems an unfortunate oversight
  • Please get the API Manager image(s) into the ECR repo, since that was indeed available via Bintray
  • Please also be sure to continue to offer (in both the ECR and Dockerhub repos) all the different updates/versions for each image, as it can be so valuable to run things against an image with a specific CF version and update level, which the Bintray repo did offer
  • Please correct the CF Docs page for the Docker images to mention and the availability of the AWS ECR images, and incorporate their use into the page
  • Please correct the "usage" tab for ALL the ECR images to clarify that the full ECR path must be used. For example, coldfusion:latest will not work with these
  • Please also update the docker run examples there to show at least one example exposing ports. You should probably also add a mention (at the bottom of that "usage" tab info) how the docs page covers environment variables, property-based config, compose files, and more
  • I will re-read this tomorrow and see if I missed any points above

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
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:
https://coldfusion.a...
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):

https://tecadmin.net...

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):
https://kevingimbel....

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):
https://cfswarm.inle...

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:
https://pspdfkit.com...

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):
https://techcommunit...

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
Yeah, these changes are annoying for sure. I now see I burned unnecessary time changing my dev environment onboarding instructions/scripts to support downloading the tar images just to now have the moving target change. I would hope/think that once they're set up on Docker Hub (with images actually being posted on the account), things should start stabilizing.

I made the regrettable mistake of getting my new work computer as an M1 mac since my impression was that Docker would just run x86 images in emulation, which is true, but the caveat is some emulated images may have bugs/crash. Of course Adobe's images are in that camp. :( I may be at the breaking point of just trying the Ortus images just to Get Things Done. I have nothing against them, just the purist in me prefers using official images from the vendor with stuff, but this recent mess-up and the M1 issues have pushed me over.

Any advice where I may be lacking is welcome.
# Posted By Josh Curtiss | 8/5/21 11:18 AM
Josh, as for the Mac issues, did you try the prerelease and its new images? I didn't check if they include m1 support. They may. See prerelease.adobe.com, or a blog post I did with more:
https://www.carehart...

Let us know how it goes.
# Posted By Charlie Arehart | 8/5/21 11:27 AM
Hey Charlie, I did not see any images in the prerelease section. Only the serverless stuff.
# Posted By Josh Curtiss | 8/9/21 8:24 AM
Josh, I concur that I don't see any docker images now, either (at least, viewing the prerelease site on my phone).

First, they were offered when the prerelease was at full functionality in July. But literally the day after I offered the post I mentioned in my previous comment here (about the prerelease), Adobe pulled the rug out, removing the planned Azul support, and the installers. I guess if the docker images also embedded Azul, they need to replace that in them, so now we await that.

Second, I had not noticed this when I replied to you here a few days ago. But rather than just wait to see what happens, you could ask Adobe on the prerelease in their forums at:

https://forums.adobe...

Feel free to offer the link if you do, or news if they reply.
# Posted By Charlie Arehart | 8/9/21 8:47 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