1

Our requirement is to create a container for legacy apps over docker.

We don't have the operating system support/application server support available, nor do we have knowledge to build them from scratch.

But we have a physical instance of the legacy app running in our farm.

We could get an ISO image from our server team if required, our question is if we get this ISO image can we export this as a docker image?

if yes, please let me know if there is any specific procedure or steps associated with it.

if no, please tell me why? and the possible workarounds for the same.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Rakshu
  • 11
  • 4
  • What are your goals in moving from a physical host to a container? – BMitch Sep 05 '18 at 13:41
  • i would need to create multiple instances of legacy apps with minimal hardware footprint. – Rakshu Sep 05 '18 at 13:52
  • 1
    As you’ve described the problem and your available resources, migrating it to a virtual machine (and not Docker) will be a better match. “Migrate a physical system to a VM” I believe to be a common task, as is “install a VM from an ISO image”, but most Docker workflows start from source code and an unconfigured OS image (even for proprietary apps). – David Maze Sep 05 '18 at 14:04

2 Answers2

1

You will need to reverse engineer the application dependencies from the artifacts that you have in access to. This means recovering the language specific dependencies (whether python, java, php, node, etc). And any operating system level packages/dependencies that are required.

Essentially you are rebuilding the contents of that ISO image inside your docker file using OS package installation tools like apt, language level tools like pip, PECL, PEAR, composer, or maven, and finally the files that make up the app code.

So, for example: a PHP application might be dependent on having build-essential and php-mysql installed in the OS. Then the app may be dependent on packages like twig and monolog loaded through composer. If you are using SASS you may need to install ruby as well.

Your job is to track all these down and create a docker file that reproduces the iso image. If you are using a common stack like a J2EE app in tomcat, or a php app fronted by apache or ngnix, there will be base docker images that will get you most of the way to where you need to go.

It does look like there are some tools that can do this for you automatically: Dependency Walker equivalent for Linux?. I can't vouch for any of them. But you can also use command line tools. For example this will give you a list of all the user installed packages on a fedora system:

sudo dnf history userinstalled

When an app is using a dependency manager like composer or pip, there is usually a file that lists all the language specific dependencies.

At the end of the process you'll have a portable legacy app that can be easily deployed anywhere with a minimal footprint.

As one of the comments rightly points out, creating a VM from the ISO image is another way forward that will be much easier to accomplish. The application dependencies won't be explicit, but maybe that's ok for your use case.

Robert Moskal
  • 21,737
  • 8
  • 62
  • 86
  • Thanks for you valuable inputs, IS reverse engineering the only way to go or can you suggest any third party apps or tools which can convert ISO images into Docker image? As I specified we have minimal hardware footprint and going the VM options seems less unlikely for a considering the cost associated with it – Rakshu Sep 05 '18 at 14:31
1

if we get this ISO image can we export this as a docker image?

I don't think there is an easy way (like push-the-export-button) to do this. Explanation follows...

You are describing a procedure taking place in the Virtual Machine world. You take a snapshot of a server, move the .iso file somewhere else and create a new VM that will run on a Hypervisor.

Containers are not VMs. They "contain" all the bytes that a service needs to run but not a whole operating system. They are supposed to run as processes on the host.

Workarounds:

You will have to get your hands dirty. This means that you will have to find out what the legacy app uses (for example Apache + PHP + MySql + app code) and build it from scratch with Docker.

Some thoughts:

  • containers are supposed to be lightweight. For example one might use one container for the database, another one for the Apache etc... Your case looks like you are moving towards a fat container that has everything inside.
  • Depending on what the legacy technology is, you might hit a wall... For example, if we are talking about something working with old php, mysql you might find ready-to-use images on hub.docker.com. But if the legacy app is a financial system written in cobol, I don't know what your starting point might be...
tgogos
  • 23,218
  • 20
  • 96
  • 128