Abstract Application and Data Naming (AADN)

There are many conventions for where to place packages on a server. Many of these suffer from various flaws, and most of them share similar concepts. AADN takes the best aspects and includes enhancements for some of the flaws. Some of the current means of naming applications are compiled.

Goals and Concepts of AADN:

Seperation of Data repositories from Application

This allows for easy application upgrades, without having to migrate data from one folder or other, and without accidentally overwriting data.

Concurrently host multiple version of same Application

By naming applications discretely based on their version, it is possible to have multiple versions of the same application, on the same host. This is also useful for staging upgrades of an application, while still allowing for a rollback.

Application Encapsulation

Each application is encapsulated into its own folder. This keeps applications from polluting the file space of other apps, and makes for easier long-term management of the application.

AADN Defined

Two root folders exist: /app and /data. Application data is seperated from the application base directory.

Application Root (/app)

Within /app is a folder for each application, named as:

{application}-{version}

A pseudonym 'abstract' symbolic link is then created to the application version, and all configuration files and external scripts should use the abstract symbolic link. The benefit here is transparent application upgrades (just relink to the new version).

A few examples:

/app/apache-2 -> apache-2.0.53
/app/apache-2.0.53
/app/apache-1 -> apache-1.3.33
/app/apache-1.3.33
/app/java1.3 -> java1.3.1_02
/app/java1.3.1_02
/app/mysql -> mysql-4.1.5-sparc32
/app/mysql32 -> mysql-4.1.5-sparc32
/app/mysql64 -> mysql-4.1.5-sparc64
/app/mysql-4.1.5-sparc32
/app/mysql-4.1.5-sparc64

Data Root (/data)

Within /data exist folders, similar to their application parents. Because data needs are more varied, the data folders may be grouped named by the application abstract name, or they may not. The version of application should only be used where it is relevant. For instance, a database may change file formats between major versions. This will be a good reason for keeping one database data root from another. There may also be more than one folder for the application.

A few examples:

/app/mysql-data -> mysql-data-4.x
/app/mysql-data-4.x
/app/mysql-backup
/app/apache

Mount Points

Typically, /app does not require a different mountpoint. It should be located on different disk from the Operating System, to make OS upgrades more convenient. However, /data will likely require its own mount point, if not multiples. If only one mount point is used for all applications, /data can be its own mount point. If more, than /data should be on the root directory, and each folder underneath /data should be a mountpoint. It is possible that multiple mountpoints exist for a single application, at which point they should each be mounted underneath /data/{app}.