No mention of a docker version still, any update on this?

[Doug Cain]

One of the features promised for this release was a container version, but no sign of it yet.

Is this still coming?

[raksh_naresh]

The official Docker images will be available within a couple months for ColdFusion 2016. Once ColdFusion 2018 is released we will have the Docker images for 2018 too. The reason you do not see a specific mention of Docker in the feature list is because it is not tied to 2018 release as such.

[Doug Cain]

Interesting your also doing it for 2016 but surprised its not part of the Beta. I'm sure there are plenty of people who want to give feedback on such a feature.

[sureshjayaraman]

It can be out anytime we are working on some legal and approval issues . 

[andreass67239098 · Accepted solution]

Have a look here: https://bintray.com/eaps/coldfusion/cf:coldfusion/2016.0.6

[CFJSGeekOmaha]

Please explain what we'd be looking at if we clicked that link.

[andreass67239098]

It looks like the official docker Adobe ColdFusion 2016 image published by Adobe Systems.

[CFJSGeekOmaha]

Nice find! I'm quite new to Docker, but it appears to be an image that takes basic environment variables and then you have to run a .CFM file with admin API calls to setup the rest like DSN.

They only give internal-webserver (port 8500) examples. I'm not positive how the web server connectors would be setup (normally done with wsconfig). I see the CF add-ons are a separate image, but that leaves things like .NET and SOLR CF services possibly still there, which seems to violate the one service per container rule I've heard. Be interested to know about all that.

I haven't played around with Windows containers yet, but I'm assuming this would be a Linux container.

Excited to play around with this. I wonder why they choose JFrog over Docker Hub?

[ImmanuelNoel]

CFJSGeekOmaha​,

Like you said the ColdFusion Docker image takes up environment variables to configure basic settings, and the idea is users extend the image to customize it to their requirement.

The ColdFusion image contains the barebones server only, and not addon services such as Solr and PDF. Those services are contained only within the ColdFusion Addons image. .NET service does not exist since we only provided containers for Linux. We did not provide Windows containers since we saw performance issues on those containers, and because Linux containers work very well on Windows.

Now, the ColdFusion image only runs on the bundled server. You could bring up a new container based off httpd 2.4 (https://hub.docker.com/_/httpd/ ), and follow the instructs at Setting up ColdFusion in distributed envionment | Adobe ColdFusion Blog​ , to setup the Apache WebServer on another container, and tie it to ColdFusion. Based on feedback, we could evaluate providing a new connector image along with ColdFusion and Addon images. 

Lastly, we choose JFrog over Docker Hub due to licencing and distribution issues.

Looking forward to feedback on how the container is being used, and on optimizations that could improve the experience.

[Doug Cain]

Immanuel Noel​,

It looks like you have a very limited set of environment settings available so i'm not sure how you propose we configure the CF engine, what is the best practice here?

As far as I can see there are a few options:

1. use the environment setupScript to run a bunch of calls to the admin api (not all settings are available though)
2. increase the scope of the environment variables to cover all cf settings
3. have a separate config file for the container (no different to 2 really)
4. manually change the xml files directly in the container as part of the build / mount them as a volume to external versions

I currently do number 1 / 4; a volume the jvm.conf file to setup class paths / memory etc. and a script for the admin api to setup DSN's

Not the cleanest setup so it would be nice to have a lot more control of the underlying CF settings when creating the container. Would also be nice if it doesn't goto the migration screen in the CFIDE on startup.

[Aquitaine]

Adobe has some catching up to do with configuration management. Commandbox and CFConfig can do everything you need without messing around in XML. We don't go near CF containers without it.

[Doug Cain]

I agree, I have used CFConfig and it works quite nicely but command box didn't fit my needs (runs as a WAR installation).

Adobe you will need to address this so configuration can be scripted.

[Aquitaine]

You don't have to use Commandbox to run the server. You can use it just to import the configuration to a traditionally-installed CF engine.

[Doug Cain]

Interesting thought, although I guess you have to install command box in the container and pass the json in. Will give it a go.

I wouldn't expect to have to jump through these hoops for an official Adobe container though, its been a pain point of CF for a long time.

ImmanuelNoel​'s thought of a CAR is interesting but rather static and not so easy to manage (read script) and my milage has varied wildly with them.

Implementing something like CFconfig would be the best solution I think for Adobe.

[Aquitaine]

IIRC the trouble with that is that Commandbox runs (internally) on Lucee. But it is a problem that needs to be addressing and if I were Adobe I'd rather have a little egg on my face by embracing a tool relying on the competition than go to the tremendous lengths they've pretty much been forced to go to in duplicating effort.

Even that would be more-or-less OK if the duplicative effort produced a similar result, but it's not a criticism of Adobe engineers to say that CAR files and XML editing don't even come close to CF Config. It's a criticism of the business reality they're forced to deal with.

I don't have a horse in this race but it has been the case for several years now that Adobe has been made to do a lot of hard work to not only no effect, but negative effect, as we saw today at the ITB Keynote when the official Adobe CLI was super slow and clunky. Every person in the room had to be wondering -- "why would anyone use this?"

We're Adobe customers and likely to remain that way -- there are a variety of reasons for this, but I really wish that the business side of Adobe would stop forcing the engineering side to waste time on re-inventing wheels that have been working well for some time.  I appreciate the legal and marketing challenges. But the current strategy of "we'll just make our own of everything" puts them so far behind and poor Immanuel has to show up and try to paint a pretty picture out of it. I know nobody seriously thinks that this approach is a best practice in 2018. I would really like for Adobe to own where they haven't been successful along with where they have been. Instead we get the same CF Keynote about how CF is the most productive software in the history of software that I've seen three times since CF Summit.

It's OK to not be great at everything. Can we stop pretending now?

[ImmanuelNoel]

Thanks for your feedback, Doug, and Aquitaine.

At this point, we have three options to bring in configurations to the container. Like Doug mentioned, scripting AdminAPIs and mounting volumes for configuration files such as JVM.config / neo-*.xml files, are two ways to do it.

You could also mount a directory that has CAR archives into /data, and configurations in the archive would be automatically imported during container startup.

We have an issue importing data-sources and scheduled-tasks in this fashion, and are tracking internally to have full support for CAR at the earliest.

[CFJSGeek]

One thing I thought of last night, it would be super helpful to be able to define the JVM startup arguments such as min/max heap, GC, etc. I haven't figured out how you'd update the JVM yet as part of the container install process, but guessing access to the JVM path would help as well. Probably would have to do a post-install YUM install for Java.