{"id":21175260,"url":"https://github.com/avisonovate/config","last_synced_at":"2025-07-09T21:31:51.417Z","repository":{"id":31605737,"uuid":"35170675","full_name":"AvisoNovate/config","owner":"AvisoNovate","description":"Configure a system using EDN files and clojure.spec","archived":false,"fork":false,"pushed_at":"2018-07-13T15:22:53.000Z","size":119,"stargazers_count":73,"open_issues_count":1,"forks_count":6,"subscribers_count":17,"default_branch":"master","last_synced_at":"2024-05-09T13:48:08.160Z","etag":null,"topics":["clojure","component"],"latest_commit_sha":null,"homepage":"","language":"Clojure","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/AvisoNovate.png","metadata":{"files":{"readme":"README.asciidoc","changelog":"CHANGES.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-05-06T16:36:21.000Z","updated_at":"2023-10-23T18:13:41.000Z","dependencies_parsed_at":"2022-08-24T02:41:14.629Z","dependency_job_id":null,"html_url":"https://github.com/AvisoNovate/config","commit_stats":null,"previous_names":[],"tags_count":18,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AvisoNovate%2Fconfig","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AvisoNovate%2Fconfig/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AvisoNovate%2Fconfig/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AvisoNovate%2Fconfig/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AvisoNovate","download_url":"https://codeload.github.com/AvisoNovate/config/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":225597350,"owners_count":17494150,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["clojure","component"],"created_at":"2024-11-20T16:58:54.335Z","updated_at":"2024-11-20T16:58:54.999Z","avatar_url":"https://github.com/AvisoNovate.png","language":"Clojure","funding_links":[],"categories":[],"sub_categories":[],"readme":"= Config - Smart and flexible system configuration\n\nimage:http://clojars.org/io.aviso/config/latest-version.svg[Clojars Project, link=\"http://clojars.org/io.aviso/config\"]\n\nConfig is a very small library used to handle configuration of a server; it works\nquite well with a system defined in terms of\nlink:https://github.com/stuartsierra/component[Stuart Sierra's component library].\n\nlink:https://medium.com/@hlship/microservices-configuration-and-clojure-4f6807ef9bea[This posting] provides\na lot of detail on the requirements and capabilities of config.\n\nlink:http://avisonovate.github.io/docs/config/[API Documentation]\n\n== Overview\n\nConfig reads a series of files, primarily from the classpath.\nThe files contain contain configuration data in\nlink:https://github.com/edn-format/edn[EDN] format.\n\nThe files are read in a specific order, based on a set of _profiles_.\nThe name of the file to read is based on the profile and the variant (described shortly).\n\nThe contents of all the configuration files are converted to Clojure maps and are\ndeep-merged together.\n\nThe intent of profiles is that there is an approximate mapping between components and profiles:\ngenerally, each component will have exactly one profile.\n\nEach component may, optionally, define a link:http://clojure.org/guides/spec[spec] for its configuration\ndata.\n\nBut what about the\nlink:http://12factor.net/config[12 Factor App]'s guideline to store configuration only as environment\nvariables?\nThis is embraced by config, because the files may contain environment variable references that are expanded\nat runtime.\n\nAt link:http://www.aviso.io/[Aviso], we use these features in a number of ways.\nFor example, for quick testing we combine a number of microservices (each of which\nhas its own configuration profile and schema) together into a single system.\nMeanwhile, in production (on AWS) we can build a smaller system with a single microservice.\nWe can also provide an additional configuration file that enables configuration overrides based on environment variables\nset by CloudFormation.\n\n== Implementing Components\n\nYou might define a web service as:\n\n[source,clojure]\n----\n(require '[clojure.spec :as s]\n         '[io.aviso.config :as config]\n         '[com.example.jetty :as jetty]\n         '[com.stuartsierra.component :as component])\n\n(defrecord WebService [port request-handler jetty-instance]\n\n  config/Configurable\n\n  (configure [this configuration]\n    (merge this configuration))\n\n  component/Lifecycle\n\n  (start [this]\n    (assoc :jetty-instance (jetty/run-jetty\n                              request-handler\n                              {:port port\n                               :join? false})))\n\n  (stop [this]\n    (.stop jetty-instance)\n    (assoc this :jetty-instance nil))\n\n(s/def ::port (s/and int? pos?)\n(s/def ::config (s/keys :req-un [::port])\n\n(defn web-service\n  []\n  (-\u003e (map-\u003eWebService {})\n      (component/using [:request-handler])\n      (config/with-config-spec :web-service ::config)))\n----\n\nThis is a standard component, with the `start` and `stop` lifecycle methods,\na dependency on another component (:request-handler), and a local field\nfor the instance of Jetty managed by the component.\n\nIn addition, the component is configurable: it implements the `Configurable`\nprotocol, and receives its specific configuration as a map.\nThe configuration passed to the component conforms to the ::config spec;\nit will have a :port key.\n\nThe `configure` method is invoked before the `start` method.\n\n== Providing Configuration Files\n\nWithout configuration files, your application will not start up; you will see\nerrors about invalid specs, because there is (in this example)\nno :web-service top-level key, and no :port key below that.\n\nConfiguration files are located on the class path, within a `conf` package; this means inside\nthe `resources/conf` folder in a typical project.\n\nFor the :web-service component, you would\nprovide a default configuration file, `web-service.edn`:\n\n[source,clojure]\n----\n{:web-service {:port 8080}}\n----\n\n== Starting the System\n\nAnd finally, build and start a system from all this:\n\n[source,clojure]\n----\n(let [system (component/system-map\n               :web-service (web-service)\n               :request-handler (request-handler))]\n    (-\u003e system\n        (config/configure-using nil)\n        component/start-system))\n----\n\nThe `configure-using` function reads the configuration files and assembles the configuration map,\nthen applies the the configuration to each component.\n\nThe second parameter to `configure-using` is map of options.\n\n`configure-using` generates default profiles from components in the system.\nAny component that declared a configuration key using `with-config-spec`\nwill be included.\n\nHere, the default list of profiles is just :web-service.\n\nThe :web-service keyword is being used in three ways here:\n\n* As the component key in the system map\n* As the name of the profile for the component, identifying the configuration file(s) for the component\n* As the key within the system configuration containing the component's specific configuration\n\nUnless you have a compelling reason otherwise, you should always follow this pattern; the profile name\nshould match the configuration key, which should match the component key in the system map.\n\nThe default profiles are in dependency order.\nIf :request-handler has a configuration key, then it will be ordered ahead of :web-service, because\nthe :web-service component depends on the :request-handler component.\n\nFor each component that defines a configuration spec, `configure-using` will:\n\n* Extract the component's configuration\n* Conform the configuration\n* Throw an exception if the configuration contains invalid data\n* Either invoke the `configure` method, or associate a :configuration key, providing the conformed configuration\n\n== Configuration Overrides\n\nBut what if you want to override part of the :web-service configuration ...\nfor example, to specify a different port?\nThis is very common ... your local development configuration is going to vary considerably from\nyour deployed production configuration.\n\nThis can be accomplished in a number of ways.\n\n=== Explicit Overrides\n\nFirst off all, it is possible to provide an explicit map of overrides\nwhen constructing the configuration map:\n\n[source,clojure]\n----\n   (config/configure-using {:overrides {:web-service {:port 9999}}})\n----\n\nHowever, that option is generally intended for special cases, such as overrides\nduring testing.\n\nMost other approaches involve controlling which files are loaded to form the system configuration.\n\n=== Explicit Profiles\n\nSo if you wish to have some overrides, you could provide a configuration file named `overrides.edn`\nand ensure that is loaded after the :web-service profile:\n\n[source,clojure]\n----\n   (config/configure-using {:profiles [:overrides]})\n----\n\nImplicit profiles, via `with-config-spec` are loaded first, then explicit profiles in the options.\nOrder can be important here, and later-loaded profiles will override earlier profiles\nif there are conflicts.\n\n=== Variants\n\nAnother option is to support an additional _variant_ to customize the configuration.\n\nFor each profile, config searches for any variant.\n\nIn this case, the file name would be `web-service-production.edn`.\n`web-service` comes from the profile and `production` from the variant.\n\n[source,clojure]\n----\n   (config/configure-using {:variants [:production]})\n----\n\nThe nil variant (`web-service.edn`) is always loaded first to provide the defaults,\nthe provided variants (when they exist) overlay the nil variant.\n\nIn this example, the normal configuration is safe; it's for local testing.\nOnly when deploying to production does the :production variant get added in.\n\n=== Additional Files\n\nYou could also explicitly load one or more configuration files stored on the file system\n(rather than as classpath resources):\n\n[source,clojure]\n----\n   (config/configure-using {:additional-files [\"overrides/production.edn\"]})\n----\n\nThis is another possible way to provide overrides that only apply in production;\nthe difference being that this file is on the file system, not packaged inside the\napplication JARs.\n\n== Runtime Properties\n\nOften, especially in production, you don't know all of the configuration until\nyour application is actually started. For example, in a cloud provider,\nimportant IP addresses and port numbers are often assigned dynamically.\nThis information is provided to the processes via environment variables.\n\nAlthough this information _could_ be extracted by startup code, and provided\nto the `configure-using` function using the :overrides configuration, that\nis both rigid and clumsy.\n\nInstead, it is possible to reference these dynamic properties inside the configuration\nfiles using the special reader macros supplied by config.\n\nProperties are:\n\n  * Shell environment variables.\n\n  * JVM System properties.\n\n  * The :properties option, passed to `configure-using`.\n\nThe following reader macros are available:\n\n#config/prop::\n    Accesses dynamic properties.\n    The value is either a single string key, or a vector\n    of string key followed by a default value.\n\n#config/join::\n    Joins a number of values together to form a single string; this is used when\n    an building a single string from a mix of properties and static text.\n\n#config/long::\n    Converts a string to a long value.  Typically used with #config/prop.\n\n#config/keyword::\n    Converts a string to a keyword value. Typically used with #config/prop.\n\nHere's an example showing all the variants:\n\n[source,clojure]\n----\n{:connection-pool\n  {:user-name #config/prop [\"DB_USER\" \"accountsuser\"]\n   :user-pw #config/prop \"DB_PW\"\n   :url  #config/join [\"jdbc:postgresql://\"\n                       #config/prop \"DB_HOST\"\n                       \":\"\n                       #config/prop \"DB_PORT\"\n                       \"/accounts\"]}\n :web-server\n {:port #config/long #config/prop \"WEB_PORT\"}}\n----\n\n\nIn this example, the `DB_USER`, `DB_PW`, `DB_HOST`, and `DB_PORT`, and WEB_PORT environment variables\nall play a role (though `DB_USER` is optional, since it has a default value).\n\nIn the final configuration, the key [:connection-pool :url] is a single string, and the key\n[:web-server :port] is a long (not a string).\n\n== License\n\nConfig is available under the terms of the Apache Software License 2.0.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Favisonovate%2Fconfig","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Favisonovate%2Fconfig","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Favisonovate%2Fconfig/lists"}