loading...
JFrog

The JFrog Platform - The New File System Layout

eldadak profile image Eldad Assis ・2 min read

What

In the new JFrog DevOps Platform, we changed all of our products to use a common file system layout, and a single system configuration file.

We defined a few important requirements for this change to take place:

  • Clear separation of immutable application files and configurations from mutable configuration, data and logs

  • Intuitive structure that will be easy to navigate and understand its context

  • Easier customizations for customers who use multiple mounts for various needs (like logs, data and configuration files)

  • A single system configuration file for the product and its services

Why

We applied various best practice principles along with customer feedback, to meet multiple product needs:

  • Clear separation of immutable application files (binaries, scripts, tools and internal configurations) from mutable data and configuration files (data, configuration and logs)

  • Easy management of configuration as code using modern configuration management tools

  • Similar installation and configuration UX between different JFrog products

  • Easy navigation and intuitive context

How

We aligned all products to use a similar file system layout.

The new file system layout provides a clear separation of immutable application files (JFROG_HOME/<product>/app) from mutable data, logs and configuration files (JFROG_HOME/<product>/var).

When you install a product, the layout follows the pattern shown in the table below. It has a clear and intuitive structure.

JFROG_HOME
  └── <product>
     ├── app
     │   ├── bin
     │   ├── run
     │   ├── doc
     │   ├── third-party
     │   │   ├── java
     │   │   ├── yq
     │   │   └── others
     │   ├── <service>
     │   │   ├── bin
     │   │   └── lib
     │   └── misc
     │
     └── var
         ├── backup
         │   └── <service>
         ├── bootstrap
         │   └── <service>
         ├── data
         │   └── <service>
         ├── etc
         │   ├── system.yaml
         │   ├── <service>
         │   └── security
         │        ├──master.key
         │        └──join.key
         ├── log
         │   ├── <service logs>
         │   └── archived
         │    └── <archived service logs>
         └── work
             └── <service>

See more details in our Wiki.

Some notes

  • In Linux based installations (RPM, Deb and Docker)

    • JFROG_HOME=/opt/jfrog
    • $JFROG_HOME/<product>/var is a symlink to /var/opt/jfrog/<product>
    • To customize the location of the mutable directory:

      • Set the JF_PRODUCT_VAR environment variable before running the installation
      • Mount whole the JFROG_HOME/<product>/var on a dedicated persistent storage
      • Using soft links in JFROG_HOME/<product>/var, the user can further customize the final location of mutable files (for example, in Artifactory, point the log directory to a dedicated /mnt/jfrog/artifactory/log directory with a simple ln -s /mnt/jfrog/artifactory/log $JFROG_HOME/artifactory/var/log one time command as part of the initial setup)

The system.yaml

Another important change we introduced is a single, YAML-formatted file for managing the application's system configuration (not to be confused with application configuration).

The system.yaml, which is located in JFROG_HOME/<product>/var/etc, holds the system configuration for your product and its services system configuration.

For example

  • Database connection details

  • Configuration of join key

  • Service ports

  • Log configurations

  • Many more...

You can also find a system.full-template.yaml file in the same directory with all supported configuration keys and their default values.

Take extra care when changing configuration values.

You can find more detailed information about this file in our Wiki.

Posted on by:

eldadak profile

Eldad Assis

@eldadak

An architect solving platforms and infrastructure problems...

JFrog

JFrog products seamlessly integrate with practically any development environment on Earth, from legacy code to the most recent containers and micro-services.

Discussion

pic
Editor guide