Properties/configuration

properties is file containing a set of key value mappings (in different formats ie json/yaml/properties) that are constants used in the app for specific environments (ie same keys but different values for different environments)

Types of properties

  • deployment

    • These are necessary to start the application up

      • ie java options, which env to deploy to

    • They can also be used as a precondition before startup.

      • if not set or are wrong, then application cannot startup (obvisouly should be done before it gets to deployment)

  • startup

    • These are needed for the app to run, after being deployed.

    • If they are not there then the application cannot do it's tasks

    • ie database properties

  • In life properties

    • These properties can be changed throughout the lifecycle/running of the application

    • ie 3rd party url, toggles, certificates

  • Secrets

    • These are generally things like passwords, usernames, tokens, private keys

    • They need to be encrypted when saved or stored anywhere (ie db/git), but upon deployment or usage needs to be decrypted

      • Either by the devs or someone with clearance

    • Generally decrypted on the environment/server, so the application can use them to function

      • This means they should never be shown in logs (or at least obfuscated), accessed by some user via the application (ie endpoint)

    • These secrets will generally have self life where they become out of date and need to be replaced (ie encrypted and stored)

  • Local properties

    • these are a file which is a combination of all the above.

    • Where the property file is used by the app when done on a local environment ie dev computer, minikube etc

      • They can also be used when running the build ie all the tests, or running a test, or running the app via the main method, or docker container

    • Secrets would not be encrypted, unless decryption happens in the app (but this is not a good idea as the decryption key would need to be in the app)

Property manager

  • applications which manage the properties

  • Use during the phases of the application (deployment, startup and inlife)

  • Do not need to go through whole software process, ie change code

    • They are dynamic changes

    • The application will have system to call or listen for changes in the the PM and apply them ie for inlife properties

  • Non developers can change it

    • Secruity reasons ie changing production passwords/certs, should be done by as few people as possible

  • Can have properties passed in at time of deployment

    • the deployment system ie kubernetes, will pass in the properties at deployment and startup

  • drawback

    • Not versioned control, lack of audits on who did what and hard to roll back

      • although this can be implemented

    • Properties changed while the application is running, may be reverted on the deployment of a new version of the application and thus lost

      • Need to remember to add these to the permenant property file for future versions

      • although the dynamic property might have been short lived, and not needed permenantly

    • Another DSL to learn

Secret Management

  • Vault

Other

  • Can separate CI and CD

    • When CI is complete a binary/jar/image is versioned and produced

    • The CD is configured with the version of the app which is ready to be deployed

    • The CD can now deploy to different environments (with different properties settings) independently instead of deploying in a set order (ie CI->test -> stage -> prod)

    • So we can do a release/deployment to prod with just changes to inlife properties to a version already in prod

Separating properties from app in different projects

  • stop deploying full app and only properties

Other

  • Use of environment variables in properties ie local database url

Links

  • https://docs.oracle.com/javase/tutorial/essential/environment/properties.html

PreviousOn Premises HostingNextRelease process

Last updated