{"_id":"kit-deploymentizer","_rev":"202-f4354ae90f4ed0654d7de0668b38f295","name":"kit-deploymentizer","dist-tags":{"PRERELEASE-v2":"2.1.10-PRERELEASE-v2.0","PRERELEASE-image-sha":"4.6.35-PRERELEASE-image-sha.0","PRERELEASE-envs-206":"4.6.30-PRERELEASE-envs-206.0","PRERELEASE-EV-1421-promise-bugfix":"4.6.31-PRERELEASE-EV-1421-promise-bugfix.0","PRERELEASE-EV-1429-resource-label":"4.6.30-PRERELEASE-EV-1429-resource-label.0","PRERELEASE-EV-1579-git-ref":"4.6.34-PRERELEASE-EV-1579-git-ref.0","PRERELEASE-partial-content-err":"4.6.34-PRERELEASE-partial-content-err.0","latest":"4.6.38"},"versions":{"2.0.0":{"name":"kit-deploymentizer","version":"2.0.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.0.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"21b0a4174b458799e4632608c7b187e4c1b8ced8","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.0.0.tgz","integrity":"sha512-oTBb86Bgw+VoeNRXJEWZfLuq+Zdafw/lKIpPNbhiyWr9kBOJpomxp/zuvr5jIcCLNVLAFMW3wT7wrq34t600bw==","signatures":[{"sig":"MEYCIQCxFT04rqX7rVl0vOiW94Prhlbvj00G7VCbSBsd3ohv2QIhAOIo5LTcF9wHM1fdFCNMAPH5Hf98/GfYksVSU88JOY9q","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"21b0a4174b458799e4632608c7b187e4c1b8ced8","scripts":{"lint":"eslint src test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.8.9","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"6.2.0","dependencies":{"glob":"6.0.4","lodash":"4.3.0","log4js":"0.6.33","mkdirp":"0.5.1","rimraf":"2.5.2","js-yaml":"3.5.2","bluebird":"3.2.2","commander":"2.9.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.0.0.tgz_1465485376724_0.12846881989389658","host":"packages-12-west.internal.npmjs.com"}},"2.1.0":{"name":"kit-deploymentizer","version":"2.1.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"4bc604e6ea0598ecaea371c760d2b662dc6af2d9","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.0.tgz","integrity":"sha512-6CYKioYvtcCRhPMudaxiteeW7Jn/y5AXsxlB2Uu3Jvkm0cjyAQp6yEe8JF9DUQrB+n7lkfrkvUY+DG7o2odOlA==","signatures":[{"sig":"MEUCIBuke/jJFM+qGuMUPYdVI2SQnCTgHJyQ9irTm5dwn+TqAiEAjSMB/+xfTkUDOd8SO+/vLONT43KdiUwUgHasss2GfO8=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"4bc604e6ea0598ecaea371c760d2b662dc6af2d9","gitHead":"332ab0e80e692ac9ad22dee8f7fac915ab1fdd36","scripts":{"lint":"eslint src test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"glob":"6.0.4","lodash":"4.3.0","log4js":"0.6.33","mkdirp":"0.5.1","rimraf":"2.5.2","js-yaml":"3.5.2","bluebird":"3.2.2","commander":"2.9.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.0.tgz_1465485477570_0.243903751950711","host":"packages-12-west.internal.npmjs.com"}},"2.1.1":{"name":"kit-deploymentizer","version":"2.1.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"77fa36d50fbd6c2ac9ebfc4b4addafae11963778","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.1.tgz","integrity":"sha512-6PihfMgLhlCXgUwXy0+pdVTHQHbcaltUBYpGjilGfBCcY7RGPO3C6jb0cBR02A4LlqneYMfN1BeyDWC54MkyWQ==","signatures":[{"sig":"MEQCIH66zOVhg67st94WMDeAgJSxeAFwIeuCTfvyhrAZjUG6AiA+bwBEQzNA8awdhXTIJwEzqAXY3/EpQq1JOBQ6L4Tx7w==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"77fa36d50fbd6c2ac9ebfc4b4addafae11963778","gitHead":"4abfc81274cdaf38810e05e04b89f67d0bcd06d0","scripts":{"lint":"eslint src test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"glob":"6.0.4","lodash":"4.3.0","log4js":"0.6.33","mkdirp":"0.5.1","rimraf":"2.5.2","js-yaml":"3.5.2","bluebird":"3.2.2","commander":"2.9.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.1.tgz_1465485766891_0.0901874250266701","host":"packages-12-west.internal.npmjs.com"}},"2.1.2":{"name":"kit-deploymentizer","version":"2.1.2","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.2","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"1b6f50f0b58c0eea4ef638333d8411c9f7ce8aa8","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.2.tgz","integrity":"sha512-IHPM287pjasnKPG0n9Kd0DsNMtcR1gqCnYn0BC0tdTNbYju0pwEbRuVCV86uQyMpmHvHkKYd0PVLOKG3cjD0Fg==","signatures":[{"sig":"MEUCIA1LMyViH3msExPVby0WY4ZEK+Qk2bFhjDujR7BiCkZCAiEA7Pvbua+914uL4mf5BHvJ0Jj1L+bFhtgOmElm6jPyig0=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"1b6f50f0b58c0eea4ef638333d8411c9f7ce8aa8","gitHead":"766e55d5b3962231a4c2289507c1d70af9f26bc4","scripts":{"lint":"eslint src test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"glob":"6.0.4","lodash":"4.3.0","log4js":"0.6.33","mkdirp":"0.5.1","rimraf":"2.5.2","js-yaml":"3.5.2","bluebird":"3.2.2","commander":"2.9.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.2.tgz_1465486101634_0.2926279967650771","host":"packages-16-east.internal.npmjs.com"}},"2.1.3":{"name":"kit-deploymentizer","version":"2.1.3","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.3","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"19a9df10f54751b5780dc372f140f29c826caeae","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.3.tgz","integrity":"sha512-OdvOVSTf8tIpYYC5mKSfYeYnfABATUKp4GS4uDpqcwnzaVxjsh+PxoeYZFy/2N4GuDdRkpt3evZoD5KXz2RSxw==","signatures":[{"sig":"MEUCIQCKdJrWb9EDeCUmtM96Kwhu3rK/ejS1FTr99u+rZgVifgIgCsEbiM9234xHjaUJyq6OSGpUl0P9IMV4h0F3SYw29RE=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"19a9df10f54751b5780dc372f140f29c826caeae","gitHead":"d898aeeb7f3d8e7a8a015643f7d3dfff1074fabb","scripts":{"lint":"eslint src test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"glob":"6.0.4","lodash":"4.3.0","log4js":"0.6.33","mkdirp":"0.5.1","rimraf":"2.5.2","js-yaml":"3.5.2","bluebird":"3.2.2","commander":"2.9.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.3.tgz_1465504424443_0.5093700271099806","host":"packages-16-east.internal.npmjs.com"}},"2.1.4":{"name":"kit-deploymentizer","version":"2.1.4","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.4","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"f0cf1679f03d327da316f64bbcd394f6e4d76763","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.4.tgz","integrity":"sha512-JLTteB7o8tGxwRx6svv9Njy/dTImg4570ai9TvaXm9R30e9q2BgwkLYwN8ibvYIpOP46boCxiII4daL4jUAgGg==","signatures":[{"sig":"MEQCH10c6phsLwE188KdN7SvtKEDFVERB24PPSRMdgAKxeECIQDpdle+M7MxEZApS24eMv0vzGs9IeRdPWl+ybY+LCpJ7g==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"f0cf1679f03d327da316f64bbcd394f6e4d76763","gitHead":"7c69b40a0926d8564018e51519a6b0a283672a8f","scripts":{"lint":"eslint src test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"glob":"6.0.4","lodash":"4.3.0","log4js":"0.6.33","mkdirp":"0.5.1","rimraf":"2.5.2","js-yaml":"3.5.2","bluebird":"3.2.2","commander":"2.9.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.4.tgz_1467050255799_0.7752376028802246","host":"packages-12-west.internal.npmjs.com"}},"2.1.6-PRERELEASE-v2.0":{"name":"kit-deploymentizer","version":"2.1.6-PRERELEASE-v2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.6-PRERELEASE-v2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"64cad41970b36c6b916a76b33b0dffab2d8ee289","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.6-PRERELEASE-v2.0.tgz","integrity":"sha512-2HSqFtyzUBNkqk9mU8CXX1X3AWxEzLh719IS83A/FpwsCtLt9OUUfwmka2FCRGw2MRvsjf1BL+6oiGEhrxN3Mw==","signatures":[{"sig":"MEUCIBjDbXNZYy7FQZgH8Cr1Zr+q1l7A9gZ+KAmv/1EW5IV8AiEAinMMkYDvOLnXwgxo+Uw2W63h96zrmPlbkVvD1WdXJqw=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"64cad41970b36c6b916a76b33b0dffab2d8ee289","gitHead":"1abf7e84c52ffb4056704f22199fee055151692a","release":{"fallbackTags":{"PRERELEASE-v2":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-v2"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.6-PRERELEASE-v2.0.tgz_1469467813434_0.9986120508983731","host":"packages-12-west.internal.npmjs.com"}},"2.1.7-PRERELEASE-v2.0":{"name":"kit-deploymentizer","version":"2.1.7-PRERELEASE-v2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.7-PRERELEASE-v2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"6bf5a8280cb4ee3b7759449c702ee51c14754d72","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.7-PRERELEASE-v2.0.tgz","integrity":"sha512-7DGriTFv3KuXEGdn8x65zsOTvvmjicyuq6cAWOj+VKTwLC8cLBzhJ7GfO0aOOHeXf2zioysVpCSR79SIMVFNYA==","signatures":[{"sig":"MEUCIQDs1NddCGOalh4qeMHboWuJQsjRuUOizBnSbg4f30EIawIge3SI1UGcFB/qoLKrqPnuQEcvIqukTL+GVV46DQsoxWQ=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"6bf5a8280cb4ee3b7759449c702ee51c14754d72","gitHead":"6929323a5424d1b5322e7e218b5cec8964346807","release":{"fallbackTags":{"PRERELEASE-v2":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-v2"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.7-PRERELEASE-v2.0.tgz_1469473115413_0.6204321736004204","host":"packages-12-west.internal.npmjs.com"}},"2.1.8-PRERELEASE-v2.0":{"name":"kit-deploymentizer","version":"2.1.8-PRERELEASE-v2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.8-PRERELEASE-v2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"02e30a3f0dfc15b9fc829b955b493ffdf1434844","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.8-PRERELEASE-v2.0.tgz","integrity":"sha512-F3vU+rRirjAJ3G2ecnGSX9p8YLth7OZrhWmjqJddQmMO8Ms3pjEd74R+naESqrcinepx9dp4LDwbGdi2rgms+Q==","signatures":[{"sig":"MEUCIQD3e8WnnmyAfuKE1qNriZcDR78iC5025rMD979ACWGhEwIgcwG58EST04IGTCqM+oEsGIN98MAlDiTXRd2Xafgus1k=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"02e30a3f0dfc15b9fc829b955b493ffdf1434844","gitHead":"d31f687dceddaff974163521d4d199fab3abfab0","release":{"fallbackTags":{"PRERELEASE-v2":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-v2"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.8-PRERELEASE-v2.0.tgz_1469482191950_0.35242999671027064","host":"packages-16-east.internal.npmjs.com"}},"2.1.9-PRERELEASE-v2.0":{"name":"kit-deploymentizer","version":"2.1.9-PRERELEASE-v2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.9-PRERELEASE-v2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"202a64983a38ad7a13309f3bfaee14cecd89467c","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.9-PRERELEASE-v2.0.tgz","integrity":"sha512-vA8OG8Ob59E8MSdOvvipuLnF6QXs5FP45ZN97F3Zp3/GL19Pn/bwozw4D+MwgIQ/mn9zqA44VHIe3pMmd94iCQ==","signatures":[{"sig":"MEQCICIKGT0FoCbhV6Sc7vPDeRftq1gtARhPSG9cAzLZFvTsAiBcVOzDTFGTSuvI+JFgvfN6XRgO9Lnq533oPSMT2mIA5A==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"202a64983a38ad7a13309f3bfaee14cecd89467c","gitHead":"4ebef272f9104dffb1c6b42248e9c013da8da424","release":{"fallbackTags":{"PRERELEASE-v2":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-v2"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.9-PRERELEASE-v2.0.tgz_1469484767746_0.16039470047689974","host":"packages-16-east.internal.npmjs.com"}},"2.1.10-PRERELEASE-v2.0":{"name":"kit-deploymentizer","version":"2.1.10-PRERELEASE-v2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.10-PRERELEASE-v2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"93532baeb0c5de92b5a9ae1e0c963e91b862b128","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.10-PRERELEASE-v2.0.tgz","integrity":"sha512-SmJhirMTL2Rs5J2gSY4G1bVsez/0AgEWmiJrtahnZZ/XICvj5PHONyVDOFjQT/lXND/735usyyq31ir6Nnxxyw==","signatures":[{"sig":"MEUCIDrr9QGrrFv8tng5a9C94vp5wlx4iSxyE20x1aaUqi2qAiEA07N6/tvUtE1Dmw4wmBjzixlyw+QG32nJlbyX58VDe6o=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"93532baeb0c5de92b5a9ae1e0c963e91b862b128","gitHead":"4c5fcdff45a48677762a66b9797a02497ae2a486","release":{"fallbackTags":{"PRERELEASE-v2":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-v2"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.10-PRERELEASE-v2.0.tgz_1471457688634_0.45121232769452035","host":"packages-12-west.internal.npmjs.com"}},"2.1.5":{"name":"kit-deploymentizer","version":"2.1.5","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.5","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"e5c6852673d3618a6d6c0d9938b093fa59ed8d64","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.5.tgz","integrity":"sha512-7dwu8mJfLlUW/RGZeO/ycF1uT7zLQ9e38EqgdrWO1JV0deCmUuY6zNg7j9CFBzBto3p4hOjyuVTGu3uJJMC+NA==","signatures":[{"sig":"MEUCICySYFJPPFdemG9CbihbMLYdKgAAniBnzwzpxu+6xMamAiEA5ARvw+fqmB6c6gmG964u3QW8ocooK4f1Y2khKQaYD64=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"e5c6852673d3618a6d6c0d9938b093fa59ed8d64","gitHead":"debf4afecc73b7da8104870f7b3a73fa28f62b73","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.5.tgz_1471625794106_0.9533872671891004","host":"packages-16-east.internal.npmjs.com"}},"2.1.6":{"name":"kit-deploymentizer","version":"2.1.6","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.6","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"ce113022fe6492494ec968b9ee530d57f554cbf5","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.6.tgz","integrity":"sha512-xSmhDyAJjazd9pyhzcASKxbADxinfPHFwxAbdgIaimIHTovFXyKBwH4+vVkVsfKkjY7rPVgLcbdmYVdbHUjEFg==","signatures":[{"sig":"MEYCIQD0jnRj76K5JIDofElzY218Ivijzj0P6ct7zlye1aDGqgIhAMMvR/zCTxq1IfRBsy17HQbOjCo+O2zWIDBdpF3I1kLe","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"ce113022fe6492494ec968b9ee530d57f554cbf5","gitHead":"58981505bfece61cefcd7589de5be1c5c228aeb7","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.6.tgz_1471983207359_0.7194068511016667","host":"packages-16-east.internal.npmjs.com"}},"2.1.7":{"name":"kit-deploymentizer","version":"2.1.7","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.7","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"8ea05b53cf9e1eb4a5f13ccbb0e943a163440ddc","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.7.tgz","integrity":"sha512-cma5+XrHxD3Z2TDXoFb896OGecZ2ar5qQEcOm25XoZ9qcklU1xEbYhSHGQhGPPnwUoA17AuQaoM5bOECQkqMCQ==","signatures":[{"sig":"MEUCIQDApzyINVIcxA5vQ5LNGYiyg3FHJ2fgfyh2se2EN+kdSwIgO1rw9NgyW/w4cN7vfGoyzcpnEjS07EI2gdCRoo+LRh4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"8ea05b53cf9e1eb4a5f13ccbb0e943a163440ddc","gitHead":"df629654ef581791cc39f55b372028f93a0b9939","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.7.tgz_1472055696364_0.7609895737841725","host":"packages-12-west.internal.npmjs.com"}},"2.1.8":{"name":"kit-deploymentizer","version":"2.1.8","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.8","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a69211fe16529341084812dd25b6a202a862d777","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.8.tgz","integrity":"sha512-GI53zukKOCfJChdnAnSlHVcX11bZPvijFJwpXB42KzRgN51zmB2u1rZn6qDsBpDKrNFZ005yJ0fRP3uOx6TkSA==","signatures":[{"sig":"MEUCIQDgH2refgwVKRYbUvgZfocyS8QOFIDID5GRr/c3c9y5xQIgJtcd2D2JSZjGT593zYA2M5/qAmZCNE/fciugOSXlQzU=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a69211fe16529341084812dd25b6a202a862d777","gitHead":"6ded8634c87a2ff2c4c8ca98bb942b9f21fd7fe3","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.8.tgz_1472133274584_0.4903565924614668","host":"packages-12-west.internal.npmjs.com"}},"2.1.9":{"name":"kit-deploymentizer","version":"2.1.9","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.9","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"db06717954a8dcf0649c3f9a9f47605e42f76183","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.9.tgz","integrity":"sha512-1dfuFu30x9lyR9sxZFBtrj6rZhheWPaeeyPnG8bBOmhluQZ1ceagjt5FN9gDK9YaWcG/EHhXyvcVNv9h9NvIgw==","signatures":[{"sig":"MEUCIQCncyaZZN4BBYyP/WRoy8KZbx8NSVdOcLFUHgh/Gxj9XQIgMImbI8dS3JyUNH3Frv3tWbSCKuTQPtKqSSULNSGLM4g=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"db06717954a8dcf0649c3f9a9f47605e42f76183","gitHead":"6ca0340dedf9ebc9a2bcfd43ab33d3234d54831f","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.9.tgz_1472226642009_0.11580105847679079","host":"packages-12-west.internal.npmjs.com"}},"2.1.10":{"name":"kit-deploymentizer","version":"2.1.10","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.10","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"2836f4ab9e123ba5bb87c6ec12e7d1d81b524dfe","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.10.tgz","integrity":"sha512-qPRk+mHAAnqwgMZMWHEQAMzdQaaVo8PBskq4xZhjAoRz+h7Rg45+qGP3USAb7PJQGTAkq7FjRRsw1BeOatP8xQ==","signatures":[{"sig":"MEQCIHE11tru+QGsx4YVT+VKa4lg8keVV77GBOe3df5qMhlxAiB04hAb+TgU/j17rKCob7GnhcqQlCvvJx6C2nW8fFoZKA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"2836f4ab9e123ba5bb87c6ec12e7d1d81b524dfe","gitHead":"a96921cb964c2c4b4d8bbd9a34597cedcbcf1dc3","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.10.tgz_1473376061795_0.6199920456856489","host":"packages-12-west.internal.npmjs.com"}},"2.1.11":{"name":"kit-deploymentizer","version":"2.1.11","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.11","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"3140d474b63b5a80ddf68ed669fb19b329466708","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.11.tgz","integrity":"sha512-b8ffO/t2brcd7iEoeOHfvj3GV4d3VGh+VfSLEBVu0nqZg0t6YRLsmNnF5DXGLliSkUCFvd04yewpYxED6uiU5Q==","signatures":[{"sig":"MEQCIFmGToFbBMevtnYCpgpWgXmCgDS1RCDz2z3ixJZvzoUBAiAhIHOl0k0CGnL70+RTwrgZy1ER9MHfwsFXdEpuEPowJA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"3140d474b63b5a80ddf68ed669fb19b329466708","gitHead":"0fe85d0eb2b0783af178ec088abcc82fb62723cd","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.11.tgz_1473800287481_0.9275431639980525","host":"packages-16-east.internal.npmjs.com"}},"2.1.12":{"name":"kit-deploymentizer","version":"2.1.12","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.1.12","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"c63a7d1ff2537ea25675b1f8c61a0a4b7be63f60","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.1.12.tgz","integrity":"sha512-j/NRIo0hML733gzL99/YRDzkadGmcN02gJ0L6+gsigteGFy0YKG8al8HHRbPIoI3RbEqpbkMcV8WnV0knoAe+w==","signatures":[{"sig":"MEUCIQDlRKa0CC7ZYwoY+3YIJnDptTn4EitENjwZYuOjcU7duAIgMrnWWwTtPn9rUSocONa4Fb4lxtznkIH/OeGkEJ93bdQ=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"c63a7d1ff2537ea25675b1f8c61a0a4b7be63f60","gitHead":"145ef015f476b0a3413d9a62ab27edb5806563ca","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.1.12.tgz_1473804137592_0.7932897133287042","host":"packages-16-east.internal.npmjs.com"}},"2.2.0":{"name":"kit-deploymentizer","version":"2.2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"81904acda19e81eacd2747aa03c5d89601d7171e","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.2.0.tgz","integrity":"sha512-OLvzTAh5WkYOSANimF0n2CQIrGxq5RfV05+ODjf6+5gJ9acCZn8KydYQiObrca1GpTb3fxNFjWA53BReieDILA==","signatures":[{"sig":"MEYCIQCVKYoA1bwV7Wii09OBzWHWrtUnUwcYtyerLlbY+m9SwwIhAOVj1vUl3P5kr4nQDv8e925WDE3UVIcARvT1Y7YhDBVo","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"81904acda19e81eacd2747aa03c5d89601d7171e","gitHead":"5e14f81449fe2ded45252522d5d98974d4581b08","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.2.0.tgz_1473978511412_0.6986618505325168","host":"packages-16-east.internal.npmjs.com"}},"2.3.0":{"name":"kit-deploymentizer","version":"2.3.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.3.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"f55766393c1826d931ca0755a61db6b367edc865","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.3.0.tgz","integrity":"sha512-RKhmFhEwqwVKXQbkWKYDmptGFiaOyKyAnKDf7c+gcJ//gwDbjgyDk8bKLpnPgI+nB61KJKqcyTLH7igAhDICvw==","signatures":[{"sig":"MEYCIQDsdKWh5md1Nf+eAG8zrhuFEcghtEc/K7zaB4vyTSUldQIhAIB6LbR6P7SZu9V9rm4h94VDxPhTMcZNA+pPyUUorsTl","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"f55766393c1826d931ca0755a61db6b367edc865","gitHead":"c8a8b8e15304ad87227fbaa3c460e942755abeb5","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.3.0.tgz_1474042379473_0.33585903723724186","host":"packages-16-east.internal.npmjs.com"}},"2.3.1":{"name":"kit-deploymentizer","version":"2.3.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.3.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"f564ecf30d88f7df592f3012c5b9fc5157f0f68f","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.3.1.tgz","integrity":"sha512-z3eLPHP4QBGawhxpX/gNQvVmm65P/AkzrJi2VMW+KSWxXWZCLS0Yqb6GiHkJwMLLliWeGeLO3EyP1q2fqzFKDw==","signatures":[{"sig":"MEUCID9SUOB0Wq2sKEWZB0QNMt4a8VzoC8e4qjNq+sJwDL+HAiEA4dLiiYcRIH5czihUFXdqlZFDBXpEIicePCUpwXlJ5l8=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"f564ecf30d88f7df592f3012c5b9fc5157f0f68f","gitHead":"ebaab57a32abf35da6bbf1228e1201342d1b8781","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.3.1.tgz_1474495162285_0.5786537488456815","host":"packages-12-west.internal.npmjs.com"}},"2.3.2":{"name":"kit-deploymentizer","version":"2.3.2","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.3.2","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"81b33a4284d45fe3be8fccd727118c2ae9511e52","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.3.2.tgz","integrity":"sha512-yq6nR2eYrFTDgMtV8pCQQ2GGsfxAC9bnbRFK3gaVChP/moSYt6yf5ORvncKABwbOoZZKZPxgk9vONpbhKoOMew==","signatures":[{"sig":"MEYCIQDP1O3JMa6pguQl8tdFTt0OSsjnkuTQ7gS2CIhBXjkRwgIhAJXwgNnSYaoKF/FPlc8AYZxMcArpB9NJQbHVbhH9H7JW","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"81b33a4284d45fe3be8fccd727118c2ae9511e52","gitHead":"861055779d9b9133bb323bd7f934443659b21b0b","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.3.2.tgz_1474497947738_0.007511497940868139","host":"packages-12-west.internal.npmjs.com"}},"2.4.0":{"name":"kit-deploymentizer","version":"2.4.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.4.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"f834c449dde89fd23082337967d5accadd8bb5f9","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.4.0.tgz","integrity":"sha512-VMgQScquZVzRb0GK7yn6UgzosdLLmUiRI2qnardXEQHu7zbtoaJVETBfOXRNEX4nsobThd7hpO+okAtUxQcPpg==","signatures":[{"sig":"MEUCIQDc7ei7/OD6xrEPrg4XPo7HdSX9Qu0ys0ouBGxMltjPJQIgJayctcft/+iQxfaz6nbTsH0QSQPoLzMVmErd2RvS9eQ=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"f834c449dde89fd23082337967d5accadd8bb5f9","gitHead":"c9aeb7e3ce48d9270f7ee122ebb504ef6a04bf12","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.4.0.tgz_1476981205735_0.6335046614985913","host":"packages-12-west.internal.npmjs.com"}},"2.4.1":{"name":"kit-deploymentizer","version":"2.4.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.4.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"86a7a27eeb8608289e8412f5cf9641570d39bfb2","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.4.1.tgz","integrity":"sha512-OwCZlshr12h3aTPMQdSrbQT2qpK5yTsfA2+WqIkVoYfyn44Lu78DmWznJbOZGs0TQaJxjaJqAGScgYflIYfmnQ==","signatures":[{"sig":"MEQCIHrP5Pu2txsFIgsVF5pzE/MNJKzlLcj+hCsb9++fkALlAiAtRuvPVZLcbDaKv0/fd/Kvy9cAXKaeCPTjjEwmnmaJGQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"86a7a27eeb8608289e8412f5cf9641570d39bfb2","gitHead":"0c62fa8ff4a97de70a6dea53498859a7355adc18","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.4.1.tgz_1477078122539_0.800934876082465","host":"packages-12-west.internal.npmjs.com"}},"2.5.0":{"name":"kit-deploymentizer","version":"2.5.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.5.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a498958fbc5807250f258e13364cf6bc28d11822","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.5.0.tgz","integrity":"sha512-G8wUdmd9Yut0n6cuQxQqgWvvWlDYPnIPjWM72Cn6Cx0Uag1oaAUtVxeqwLBLQ+HDkBcXWm0oq8VPKMl6hEADGQ==","signatures":[{"sig":"MEYCIQCTTYOlQiPZyQ/otwAKUikYlODewGThlqqdIj1/guAhwwIhAPURdYTqxxUfk9y7pTQTnUFzGqE8V0wLd0Od5R8UzTDV","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a498958fbc5807250f258e13364cf6bc28d11822","gitHead":"ae2ab22288de0f9b3e59ee178360b7fa615d7988","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.5.0.tgz_1477079854103_0.010425306856632233","host":"packages-12-west.internal.npmjs.com"}},"2.6.0":{"name":"kit-deploymentizer","version":"2.6.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.6.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"d89ab06854e05dcebb9c435f43f8411203803d83","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.6.0.tgz","integrity":"sha512-NxDAlpQvpE6iFsWyqZMLB5RNJGEX9Kv6dq+QVxFRiw4U7l/kmPppun0v8xdUd3Ls/7+e2siwQ0MMT0JRmNq2SQ==","signatures":[{"sig":"MEQCIDYs4Ms86PJzyMYwjqfTMs62sohRZbBeSAYwnNXQtXlxAiA9dsVErLMNPq69XlFPJuDX0j5QF7mGNYEeIqaUlimVQA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"d89ab06854e05dcebb9c435f43f8411203803d83","gitHead":"85545ea4d8e3b9084a4d147d4add259f51abcf08","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.6.0.tgz_1481241467599_0.7472398858517408","host":"packages-18-east.internal.npmjs.com"}},"2.7.0":{"name":"kit-deploymentizer","version":"2.7.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.7.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"8f6e3bf75acba93a46a22c91de4a579962904a46","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.7.0.tgz","integrity":"sha512-S/kRGpJ+MxDMVCTgJeIPcioS8c7PPs9fNAqIfL4coT12UqyAr0jDtwp1LKG+s16nLfdm5tNDAAdsdQQWmmCAfA==","signatures":[{"sig":"MEQCIFxZhbpZ1BpCgGBExhDClXiU2UHObZt8TQmXvuCkj6osAiATiRyI2Glzq1Rw6b8pTX68MeponR5nDoarGI1Tp4f0cg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"8f6e3bf75acba93a46a22c91de4a579962904a46","gitHead":"6956d5d0aaaca00850e2e72411da292e670c3c33","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.7.0.tgz_1481494330251_0.17020971421152353","host":"packages-12-west.internal.npmjs.com"}},"2.7.1":{"name":"kit-deploymentizer","version":"2.7.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@2.7.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"39e44b9265786fa9971d54ab9ede6424d3db5c1b","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-2.7.1.tgz","integrity":"sha512-qPbYNjOzLeltZ615Dha1WCnRVRBmizRhgI44RS+H60SRXMsPFbHXUrNAPO8W8iIpOdy++AYP0Uyr0Zok68c7/Q==","signatures":[{"sig":"MEQCIGY/HB8Uur9CqjQmY4yW/k7/+y0LiFsNXG6so/U2PD0FAiBykoCpNifzGgIFu+wYYBTE3+rlerB6jo5YNnqklBHS3w==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"39e44b9265786fa9971d54ab9ede6424d3db5c1b","gitHead":"c9acdb0f7b469be18124d1c7447c261d48310e3d","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-2.7.1.tgz_1481566723539_0.35565556678920984","host":"packages-18-east.internal.npmjs.com"}},"3.0.0":{"name":"kit-deploymentizer","version":"3.0.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.0.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"1ca3029a9cc074f0bb560a63eb1d4fcca0fad8f6","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.0.0.tgz","integrity":"sha512-8xyeOuZD2NnFxcp9AAOPT0lEq8ScoFvYxxqUF55saAXiFk3WKXji//aXQ63JsXM/vx2NaHJAxifYPuYbTJrUUQ==","signatures":[{"sig":"MEUCIBDCfAc93KmRoD46DlLUvhDGv//Bp9JlmZ33CZI4q0BaAiEA44E1eO98NSDvY5xkEQ23rpGvCv0IbsdQiPcuQhmtF1s=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"1ca3029a9cc074f0bb560a63eb1d4fcca0fad8f6","gitHead":"c335f1b709dae1bb1115a845d8364df2f0ac8c8e","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.0.0.tgz_1485372771414_0.8592216151300818","host":"packages-12-west.internal.npmjs.com"}},"3.1.0":{"name":"kit-deploymentizer","version":"3.1.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.1.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a6fd0ab36fa1c8fdee7bef833491426ff58caab9","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.1.0.tgz","integrity":"sha512-TVGy9irIdDyW9EZgOPz+bpdLPa0SuFTvmQ6spQ0dil4/Tah/O5J7nKb+tQo4WnMYx2X33MPZqnHD3FptYEfamQ==","signatures":[{"sig":"MEYCIQCsSjo2S/v22wPDlQsWZd+YyXiEYTexvO7TBQUf6FWK3wIhAP0OAY4LWJMqwZGNN1u5eipg5wuj6PbQXy8LDqLMZQnV","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a6fd0ab36fa1c8fdee7bef833491426ff58caab9","gitHead":"2438f313d6ffaf5f25b4e8f64914ae522770367e","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.1.0.tgz_1485450773108_0.1834816278424114","host":"packages-18-east.internal.npmjs.com"}},"3.1.1":{"name":"kit-deploymentizer","version":"3.1.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.1.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"eb075c80a185fe88d727c443a23e0526a6ed89a6","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.1.1.tgz","integrity":"sha512-e0jaWXBgCGKTHH/LdUAiUoWvbceHXyVLw/nL+mMYRfmWpWBXAqyqvcNKs4iVN9/cLsGD/9sxrNRXryAIYyJTiQ==","signatures":[{"sig":"MEYCIQDjfJXD2gm+bsY3Gz8YiN+9qFtlnufS9GvvPwQLchBBIgIhAK86toNYnHoaC29yP+QHao8qPjxbnf0IQf7BQy1yVTGT","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"eb075c80a185fe88d727c443a23e0526a6ed89a6","gitHead":"e02582056da0322276b3e45a42b8a22d00de1d17","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.1.1.tgz_1485469440515_0.5737756174057722","host":"packages-18-east.internal.npmjs.com"}},"3.1.2":{"name":"kit-deploymentizer","version":"3.1.2","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.1.2","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a26533709ef28d6412feae0968d5e11a910d4057","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.1.2.tgz","integrity":"sha512-yTgMUwMZbx4mKWxsd/HpslBwcvO5xtThAbQSFv2UbU1s9rra2r1HgIiMB9R//oSiNo36//+2qEherutHm7KBlQ==","signatures":[{"sig":"MEQCIHYA+LjBAUfPUnSaREdsEIC9U4VoV11lzrN/g+UzfILIAiAhhdbweNqyAocdthF2JmHAhyagFCnW0SFVo6Ymne0Gbw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a26533709ef28d6412feae0968d5e11a910d4057","gitHead":"b19403c89a49c7d86760ea7d4f084c9d6d500cf3","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.9.2","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.1.2.tgz_1488484262549_0.44226285978220403","host":"packages-18-east.internal.npmjs.com"}},"3.1.3":{"name":"kit-deploymentizer","version":"3.1.3","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.1.3","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"2bcd488efd6fa276855cc5b9ced54f6092495b12","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.1.3.tgz","integrity":"sha512-OFop8m1COF0oJVHSSHKQoy8cpGyg1sTLZ8HBjPzrdz7TK1AwqL/AmZKXrKPr0QPBt7tQ0DncZ9iXvRBPLUFBrA==","signatures":[{"sig":"MEYCIQCwm15FYtKS1ATlwoD/2i19YJs4gFZUWtZXm1rhvfdkMAIhANNOyR4c5uYZe4HZQPJ8/rngk9K0BEwlLjds33C1X1CY","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"2bcd488efd6fa276855cc5b9ced54f6092495b12","gitHead":"cace0f62e911ad2af48e40f1e689f9914756d73d","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.1.3.tgz_1491329952278_0.49558125250041485","host":"packages-18-east.internal.npmjs.com"}},"3.1.4":{"name":"kit-deploymentizer","version":"3.1.4","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.1.4","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"4c1361a85cfd81d1dd9ca41a7b7ac41aefc275dd","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.1.4.tgz","integrity":"sha512-ldbzH0XRlFznJzX8cIrkIZSxXnA0xm8JBvxVYcga7JIwJtjHQokLdotuGddkTYmjJNsDGH4e8hQ+pVjwB3kFiA==","signatures":[{"sig":"MEQCIAwm2ak8Iy5GImKi4VIZV8AZJY+meg1TXg8VCrQNkHV2AiBJYxyZfAofnjCQBfrRMPC57d5OjWrVQ7f/eRlgPJ1kpw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"4c1361a85cfd81d1dd9ca41a7b7ac41aefc275dd","gitHead":"0fcafb9d286b539bb8a84a7e2581426ab558f229","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.1.4.tgz_1492092645039_0.7493601490277797","host":"packages-18-east.internal.npmjs.com"}},"3.2.0":{"name":"kit-deploymentizer","version":"3.2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"b3d7f0dba72e7fdf295652100ff5e0b98f15ee30","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.2.0.tgz","integrity":"sha512-bQ0W8YR4Jxl5xjwyhpzq9j4F4LPJptKJ8ggfkWu3OHSncg9fQ9TilKX1/xpJGRSbrbpwlC+OQUpbJif2lxlxBA==","signatures":[{"sig":"MEUCIQD3iELuRRRdgDyBN0DehSjw85D93A22QMCFfu22xPRCyQIgajZ0cvuBClFeKUbW7aJIr8xFNqgpeaEIr0YiNRIRDYk=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"b3d7f0dba72e7fdf295652100ff5e0b98f15ee30","gitHead":"afa31d5361defdceb508c569c207a466807d496d","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.2.0.tgz_1492111009881_0.48087241291068494","host":"packages-12-west.internal.npmjs.com"}},"3.2.1":{"name":"kit-deploymentizer","version":"3.2.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@3.2.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"e66c3db2ee4074590dd8b0f7e963e9b3137184dc","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-3.2.1.tgz","integrity":"sha512-KVQEysYewnf1E0ox+cKhGkbG5D+1NP8fP1S/jUTi1XIlLWMr7OrF1rkzRJZPw6ugqF/dyumJD7CqlF9vRX/GbA==","signatures":[{"sig":"MEYCIQC+zrbk0yCV1ejBre78s3T4/cw6562/2YoTsVLOInn62QIhAMZirHcCG4afDTpyq6KPrvMSjS5O5j4JBjJnmE0twfmF","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"e66c3db2ee4074590dd8b0f7e963e9b3137184dc","gitHead":"5002e33e6bf3aada9551280e950b92a46de7121b","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-3.2.1.tgz_1493648912763_0.7103909268043935","host":"packages-12-west.internal.npmjs.com"}},"4.0.0":{"name":"kit-deploymentizer","version":"4.0.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.0.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"efa92b5b494adf69604169cb94d2d849d7195b88","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.0.0.tgz","integrity":"sha512-TUdVVyhZTiLEXbZql13KJh7o27/wd06FoA8Vshf0j14Mk50I/ypww9ZAmJTChyVGZcn13uDRRgFp7/u8SF8omQ==","signatures":[{"sig":"MEUCIFDSv9/3ym6FWY5FCJLI3B9qse6iZ2kP0dqi3ZYO+R1YAiEAyyi1HM4jhwL7SzMbqoTG1HDZj6i5l8vOYxOFD/fOZA0=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"efa92b5b494adf69604169cb94d2d849d7195b88","gitHead":"660e6cff135894a4ff9bb5d789dc0aba5ac043bc","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.0.0.tgz_1495127263928_0.9123737483751029","host":"packages-18-east.internal.npmjs.com"}},"4.1.0":{"name":"kit-deploymentizer","version":"4.1.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.1.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"480e0c1fa3e278dc6e422e278779c917ea38e00d","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.1.0.tgz","integrity":"sha512-Zat7avkEAnPjMMrwN9DYzv6ksVhHNXU3M2uT88wqLEgd0oe81eIRdadRRUIuI0g8s32qVmu7sojDASxv7rNdig==","signatures":[{"sig":"MEUCIQDtvxqS8hRTIauJll+JUNASx53q04cELpyWIhFtBPflFAIgaOe7pDf8EWQlGbTv3SX4z7YSphoiAy15a8+Yb6kIerk=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"480e0c1fa3e278dc6e422e278779c917ea38e00d","gitHead":"c960ec0d942b1c94e4a740e7d20001a743eaf0f0","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.1.0.tgz_1497622830248_0.40591363701969385","host":"s3://npm-registry-packages"}},"4.1.1":{"name":"kit-deploymentizer","version":"4.1.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.1.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"6d0b4caf45bd439060bdb0cbd8b7f709b29136fc","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.1.1.tgz","integrity":"sha512-DBd9sW+96rk0UvgSLSFNNDc0CuSAlbzsoXFjlaR4ggBeO1KCaSx0chLIggvkKFkAsnA9n18o5qjHwlxvnFa/Vg==","signatures":[{"sig":"MEYCIQDFSMFFrBmB5SChF1gHT+uMmvUFhZZV1ap5PNMOOesK9gIhANoUDUo5im1JKvCoG64TPbq1XWjgzvmdQDk22iz+rT5O","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"6d0b4caf45bd439060bdb0cbd8b7f709b29136fc","gitHead":"78694f4866142708ea21b87bc272937d5927260f","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.1.1.tgz_1497887380119_0.0011340959463268518","host":"s3://npm-registry-packages"}},"4.1.2":{"name":"kit-deploymentizer","version":"4.1.2","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.1.2","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"10bf52d3d626931982f67b7288d7e5dd6dbe4605","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.1.2.tgz","integrity":"sha512-UJBwIBhlxKahOn86ZabEo2mJvxk3NWQKptK3IGdiOk/N8r1jVlqNTm+oYocsG47wV54ujbJ6o/CtfWmC024O6A==","signatures":[{"sig":"MEQCICbE2ZPp6pvaM5En50wZF10iZIWsWI71Kjzed+/zhbmJAiAtoHnSPuSp51ypYifmH93Pf/TV0hjyEQUa9/CFe1BoeA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"10bf52d3d626931982f67b7288d7e5dd6dbe4605","gitHead":"fe15a3c59c514322540dd7b2a3161268ee793ed4","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.1.2.tgz_1499362396783_0.768567705526948","host":"s3://npm-registry-packages"}},"4.2.0":{"name":"kit-deploymentizer","version":"4.2.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.2.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"3944c7e6fe477ed845f4f5ecc1d4ad3e8eccdf07","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.2.0.tgz","integrity":"sha512-WbTepkguskdZjoSX+K6QrwtN5PScg1vhPMtf2isQI5xon4Bl1N4LqpJqusvT8RzlY6qJpm19jU2uiDCoqFwXBQ==","signatures":[{"sig":"MEUCICXtyXbbsEBxAYz4t/uzwnsg0UDeFAyq2gnfm/KnEkeBAiEAqOI54d8LgcIHe/uEVcIWBWzP6UPy+mNzclznBKUIJeg=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"3944c7e6fe477ed845f4f5ecc1d4ad3e8eccdf07","gitHead":"d1609ea44a5753b5d8e2bd456b35757c2c9e157b","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.2.0.tgz_1500309852433_0.20447746571153402","host":"s3://npm-registry-packages"}},"4.3.0":{"name":"kit-deploymentizer","version":"4.3.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.3.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"20b466ef7cfceebe6d6785de22a4c1a736b1ea88","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.3.0.tgz","integrity":"sha512-ulca98mZMGyGDnQhXeU0aOkjuIu5ZJfaYVwFnutZv9J5edFtZNNP7ZpK/xU87EIcZP2Fgm5WNAWMNWtyEUcjFg==","signatures":[{"sig":"MEUCIQCgAUlVezHc2BelOhIYkmTgoMunii9KH/8WtRgkbkGgeAIgURB0VbbOMFiiYvU1ZelAtT5iKg/mYowd5eMGUBp88qc=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"20b466ef7cfceebe6d6785de22a4c1a736b1ea88","gitHead":"b8c2587e7f89d3de9c688d2b8e11cd39b4c0e785","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.3.0.tgz_1500312288380_0.5914781887549907","host":"s3://npm-registry-packages"}},"4.3.1":{"name":"kit-deploymentizer","version":"4.3.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.3.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"748251a3820346d5bb4b37eb707904527a55933b","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.3.1.tgz","integrity":"sha512-8REHypXDMGBX0Da1pQGcHN3Oa1eit4pxy1oHyInZQHpm5Gpw1RbGUtTs7M3vVisHdQMWYEsnWCEOJTgISFPCXQ==","signatures":[{"sig":"MEQCIF5BJXuKaOKPUUggGP2ULylL6YuZ/r43Vj0VVoBFvM/pAiBStmzAP15JYdGJov5CrC2arWgr9l+FUEPDmgtUBCgIeA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"748251a3820346d5bb4b37eb707904527a55933b","gitHead":"a509a37c4d7772bb8707164ded46a70299eb9dca","scripts":{"lint":"eslint src test","test":"mocha --recursive test","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.3.1.tgz_1500378432947_0.9099818528629839","host":"s3://npm-registry-packages"}},"4.3.2":{"name":"kit-deploymentizer","version":"4.3.2","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.3.2","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a07bcb58e08e0fa1d6a6aaacb53ca52705834d84","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.3.2.tgz","integrity":"sha512-K5uV/iV6pq7AIzZ35pI+wMm8J1v6tiilvmn500zgXYgVimVdZDS2oasR21NB7/JEYROneWeMR38Kryu18Kkiqw==","signatures":[{"sig":"MEQCIDuE0Ld7NOUzg2w2bEBE6uQbCdS2tYhL6an+Zng1HVPZAiBK+0JlkXTsEqnSqKzY/r1vmqhjZHlWGVeqOZ8327UXwQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a07bcb58e08e0fa1d6a6aaacb53ca52705834d84","gitHead":"80148977362991f300f10a7a2307c267ed9db4e3","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.3.2.tgz_1503675112537_0.8139118845574558","host":"s3://npm-registry-packages"}},"4.4.0":{"name":"kit-deploymentizer","version":"4.4.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.4.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"bc9a7c32db1630d532a8f53c45ffbc80b0c6745b","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.4.0.tgz","integrity":"sha512-Yq4CAaKZUp/BcBvIbgfHLnQnkR0yq7AigZDsjHkaB5itCFbPZQpDMkyFf7dGjVITHTw9ShmNv/r67Ikw1EOjxg==","signatures":[{"sig":"MEQCIAfZ/gRs6mpXjwzH0G+Zma34ic03KOHDA2Z8ypcr3CnPAiAMRu61h69TTZ0EvMzwfiEAoMxRZihU7RweWl6e86zwcg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"bc9a7c32db1630d532a8f53c45ffbc80b0c6745b","gitHead":"8bf372d914dcbf737f727ae02c7ed28cc662067d","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.4.0.tgz_1504101574144_0.6136954068206251","host":"s3://npm-registry-packages"}},"4.5.0":{"name":"kit-deploymentizer","version":"4.5.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.5.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"255352e60d7f5c273760fc8e6cbfa761d48a3a7c","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.5.0.tgz","integrity":"sha512-3NyjYtDyHoQ2z3336R/R3ZdG/jgM3En+tjBjYg1pWDzTwSU4iQy4Sa8AmnI7RZ8HLA3Vzqw/Ej1xusCxldEd8A==","signatures":[{"sig":"MEQCIDJ9woLOSgW7JCF51tF9EGQIcRhxG+chKWsxiVY+Rz4MAiA5Vb46eHk38f75i7//GVAfa12XwjXTJtgiNZAS74JWQw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"255352e60d7f5c273760fc8e6cbfa761d48a3a7c","gitHead":"76a33aecb53a61629a9ac8ac6300b2447ab31be3","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.5.0.tgz_1504126667081_0.23518413957208395","host":"s3://npm-registry-packages"}},"4.5.1":{"name":"kit-deploymentizer","version":"4.5.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.5.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a3e766c7b052ecfac31cb0ea56197d4b340fa762","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.5.1.tgz","integrity":"sha512-WhQzSJwE0sibUkN6bbjb6TWt4E3X4cG9Ai5f6EJmZbzpdsVXWVhaN34bGYZVKsjAAQc070B8RMo5QoCCzRuZJQ==","signatures":[{"sig":"MEUCICc9Y98zUHTr5ex7Rsd3Fb1qqVdoAp0EHCNfcUkCtMi3AiEA/3Ymj1/ZCG/ewUQcIcA4aHGcWe2iOuWqGPbd3cH4MZU=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a3e766c7b052ecfac31cb0ea56197d4b340fa762","gitHead":"d68e8693bb46d2b31790d29281c1c589380273d0","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.5.1.tgz_1504709302347_0.5330757584888488","host":"s3://npm-registry-packages"}},"4.5.2":{"name":"kit-deploymentizer","version":"4.5.2","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.5.2","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"adab7f48167cef3f81c713b000160344d988fe2a","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.5.2.tgz","integrity":"sha512-mG8iSbJ+6MJk+i8/PMuCpl2z8pzG/qr2XIaQ9YaDhFRTxOg/Xfm3Ywt6JWfRhhtL11Et22xdG7skM/3lNGiEnQ==","signatures":[{"sig":"MEQCIBbj2Kri7DKn9maJHitJuev+TdQi9jQg55VEp/kK7d5VAiBf5MLfpaMbgyKfK2XNbVPE1jMEqmcvCEMptT0CT+3kwQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"adab7f48167cef3f81c713b000160344d988fe2a","gitHead":"c5463c49c2d8e0102b0e3e5536fddd97911ce0e1","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.5.2.tgz_1505481593450_0.09519026428461075","host":"s3://npm-registry-packages"}},"4.5.3":{"name":"kit-deploymentizer","version":"4.5.3","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.5.3","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"5faddeba815da39382f7a01c6f15495073222b77","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.5.3.tgz","integrity":"sha512-Y+KeXJvEUQNgek+Uk+6gTMAHc3XTXmNKR/RjCH/RywvqHJj0jguOryni6LVt9cSOp1PkqhToMBRtdyc9a2+gdA==","signatures":[{"sig":"MEUCIFbVPDOMHMJtntdPKaTgjgnonW6gY2rQkaY9mRhtv54FAiEAhUWRiNe8oMf26bmSLagqKNpcivg1qGwneAh3Co7ms8E=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"5faddeba815da39382f7a01c6f15495073222b77","gitHead":"22f2cde0aadb3aa80dd5098a5690d8362b3c35f2","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.5.3.tgz_1505729457323_0.42443001084029675","host":"s3://npm-registry-packages"}},"4.5.4":{"name":"kit-deploymentizer","version":"4.5.4","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.5.4","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"3ba7681c6edf0495c4a35657e7ce552d0e71d328","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.5.4.tgz","integrity":"sha512-p6HMT0WccabEH/Ie9fj9ctx9KeWxF1w6OcrFLoA3XmZbYBQ5/EVcdlesZo0sY8dCIqgnzOmFMGhptPnv+7eUyw==","signatures":[{"sig":"MEUCIQDRYBNDFgtnf1xB8aYWRiLgjVccP4MdBTTx9PemAVfCKQIgeOIQkWeO19v6mNYjpYt3NKnWUaK0jj9koATcPFecP9o=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"3ba7681c6edf0495c4a35657e7ce552d0e71d328","gitHead":"f62391fd07e171268d0fce8537b2d44dfa3511f9","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.5.4.tgz_1505736292578_0.8360160528682172","host":"s3://npm-registry-packages"}},"4.5.5":{"name":"kit-deploymentizer","version":"4.5.5","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.5.5","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7151f5b7ab6193cee254638f951d94858ccc24a0","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.5.5.tgz","integrity":"sha512-oOLLe1/88BbS4sofKoPhoeMdrVGq/zuB49XE6Dn3WmAe+dNlIri4MGTLm/eZyr9A2MhBOOVOWtAFnySlVvEj4w==","signatures":[{"sig":"MEQCIAYJ3DwgdPzYGrkPe6rN3KcVlg4YMOZUX5rti1pguZlVAiAVXJxPu6QLv8HbYS8xxEnh+R8vRcN183teWj9nEHyjfg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"7151f5b7ab6193cee254638f951d94858ccc24a0","gitHead":"efc272b670340ab8425042e2209c1b132045a3ca","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.5.5.tgz_1505741012970_0.7783938662614673","host":"s3://npm-registry-packages"}},"4.5.6":{"name":"kit-deploymentizer","version":"4.5.6","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.5.6","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"8ca731b19d54f06c05c9e68697819fbf792d1f67","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.5.6.tgz","integrity":"sha512-YjqMaXPZP/FFVy7veDSbzOcRBDNrosZH65GMEGQnRsJcNxjfMQV8faIsBvLGvUJCqqwdavpwyIEnbOEmZBaQiA==","signatures":[{"sig":"MEQCIFDho2O2Eg2PjWGhBvHgzZiuW6v0bunEf+jd/kxNCWyKAiBvGgICFPqJvgpvW8UtEJFm7JFBC68EuSNepA+NDnS12w==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"8ca731b19d54f06c05c9e68697819fbf792d1f67","gitHead":"25f749e49000239d62d5c2f3936e3beb1539359c","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.4.1","mockery":"2.1.0","prettier":"1.5.3","eslint-config-prettier":"2.3.0","eslint-plugin-prettier":"2.1.2"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.5.6.tgz_1505749731502_0.39458946674130857","host":"s3://npm-registry-packages"}},"4.6.0":{"name":"kit-deploymentizer","version":"4.6.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"8fec3cd106192f0fadb556d9dc291df9f95296ac","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.0.tgz","integrity":"sha512-2A084BxDALAPYB/9sLbUje0qF6DUgFv73UhpdzEpvJZNIY3eziEAgtgQraTUVhptNWJS0cZF/xeYR5/MdVKWog==","signatures":[{"sig":"MEUCIQDeBT3EDbpbz+H3xRNzTkgefDCR16Glh+iAJsF3+yaRSgIgTd+7AOOLLP4ASVUlShzysY99lGYO/LjR0t7aV2eVAt4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"8fec3cd106192f0fadb556d9dc291df9f95296ac","gitHead":"7ceafb2f7a7350a96d36a5578166f9639d93dd75","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.6.0.tgz_1508433649915_0.03290272015146911","host":"s3://npm-registry-packages"}},"4.6.1":{"name":"kit-deploymentizer","version":"4.6.1","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.1","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7632c1b767926808a59118d6a82ee4e825cfa50f","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.1.tgz","integrity":"sha512-YLZ/iuFy48o7cgEahvb5c4XFaVswxlTokFRvjJoIlYa38E8EwxyZ3RP4nRC4tk0oCINN9W1LDSZ8Lxqv/iPimg==","signatures":[{"sig":"MEQCIHYYpFjWDGB6CNs3ifQ8EXvKkAqSVC1OwYSV7y+a8KRwAiBT0efSuiBqyuWzBM39NLT9TbOOi2f/aazR+fezSbaGrA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"7632c1b767926808a59118d6a82ee4e825cfa50f","gitHead":"eef9e8027519f000232b7b5d9e7379b37a42adce","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.6.1.tgz_1509108914243_0.599563603522256","host":"s3://npm-registry-packages"}},"4.6.2":{"name":"kit-deploymentizer","version":"4.6.2","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.2","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"4166ab3f831edb784974dadedfdf670fe1cc6212","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.2.tgz","integrity":"sha512-xYbJhO4B8snMnrPe3w2WsDAzyTzei1XRY7gmaKDWE605LQIPcCM7x1eBsavehOJaT46H4/G+rQUxzHQZtX2feA==","signatures":[{"sig":"MEQCIGsj0+y15KJf8oqyaj2XYs2El/4pXruncrFnfkqoGfn9AiBEPo33mFh7kYXvH44C7QeeI/SI6bxNdADa4FpONuffFw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"4166ab3f831edb784974dadedfdf670fe1cc6212","gitHead":"32543b26eaf3f6aa9da52ecc052492d6d9507eb4","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer-4.6.2.tgz_1510091370722_0.928930074442178","host":"s3://npm-registry-packages"}},"4.6.3":{"name":"kit-deploymentizer","version":"4.6.3","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.3","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"f9c63562724ea356c3f0e4d63dbe881aec350a55","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.3.tgz","fileCount":17,"integrity":"sha512-HpWbJaQOY4iMGIR/pEFZdWKgLkPRgNBuQy0BuMPsMt0MqtbrWgu5PR+I2UfRbs9E24os8fhjQSfX4dAEpqZ5rA==","signatures":[{"sig":"MEUCIQCdfhEgFZmk3f7oWaX4SixpEegx5XNWe8o/6jmvR07hjQIgJCvu/XAE4lPQSnNfRSgYE75AReXb7zYQp8y/5ZsM9cc=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":84866},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"f9c63562724ea356c3f0e4d63dbe881aec350a55","gitHead":"00847ceb9019067ddf781c21f0bd829b16c4f6c6","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.3_1519058381008_0.2764763348895434","host":"s3://npm-registry-packages"}},"4.6.4":{"name":"kit-deploymentizer","version":"4.6.4","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.4","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"45a9788ec636281f930211e054715866af04b04f","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.4.tgz","fileCount":17,"integrity":"sha512-qRSf6lO7v2VKeepWG2RdU5RRNkQeHKCxPAMOYXsbe4jAC5jCw17K31vR8j8UoVGNUAOEBaDW5y2BRTos5nUcVg==","signatures":[{"sig":"MEUCICEO0qCKztC/SZ1sm2G/CmmI4bwhOMP0b7IzTd7lBar0AiEAzi+DieXNN/yUS13gBI/eDNYwlXPFHMMBRffw71UT5zk=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":86730},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"45a9788ec636281f930211e054715866af04b04f","gitHead":"a0f7cef693059affecf5be779e01eda52c9e497f","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.4_1519853097326_0.6081902290258385","host":"s3://npm-registry-packages"}},"4.6.5":{"name":"kit-deploymentizer","version":"4.6.5","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.5","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"50a0c118e1121031c9a57f5d47668e51815fca59","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.5.tgz","fileCount":17,"integrity":"sha512-4Gjj8iPeBPLlKJWKrWe5mqZJQP3BLYv0xWtu4ImS/jdJmUXH7dfIcqWhgkqZ/X3ADo0EhOAZ8FOdORjWfNuGsg==","signatures":[{"sig":"MEQCIAC2o+JGpyna9SajQg5VWoWtw+1b+/b8duM3JbsUtqGTAiBxo/krr2v/aC8mBuSSvnDmuYJaP5vs3YdYOoc8uflSow==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":87175},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"50a0c118e1121031c9a57f5d47668e51815fca59","gitHead":"cbc17ac96c8f76c890372f1d81e8d6313d78e6cc","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.5_1520504054384_0.32993859058039643","host":"s3://npm-registry-packages"}},"4.6.6":{"name":"kit-deploymentizer","version":"4.6.6","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.6","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"0412634006c34896b5b35aee900c05f68a3bb2a8","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.6.tgz","fileCount":17,"integrity":"sha512-Yobu+3Mj7t+I0B9qqkgFNjuTSGvDLVdLue2odUK30x+yp54nwTlRICOE4muCeYDUot9tSNmn4qeCPJBWN6cZyw==","signatures":[{"sig":"MEYCIQDY2WavKWo6GXawG320wtM4blTtH3M8WmPej+Paw6r6mQIhAI7Gq/aInitXJnvTeeQIELg1zMQu1E3cKtk22MhKwz9q","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":89925},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"0412634006c34896b5b35aee900c05f68a3bb2a8","gitHead":"3568b97b5fce7b75c94d18431700cff7ce81f341","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.6_1521050254244_0.5133693128554289","host":"s3://npm-registry-packages"}},"4.6.7":{"name":"kit-deploymentizer","version":"4.6.7","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.7","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"3c93963a2b68208b839eae21c7d45b2115df73e0","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.7.tgz","fileCount":17,"integrity":"sha512-6ld7Jcb3LyiLBl8EhCUT+7+Dg/Jcu3skNL0zog+yYn+Si/u8qR10kxOMGbURgay+SYNSxCOCX2cfB5EwAHdFPg==","signatures":[{"sig":"MEQCIGMqZGMUSvup9a36qjglhmmQLNFsdCf+JmOs95gRpJNlAiAofLvfvsITYH3evE4YdjI0Yhe++TqjaPXl+pSoon3gNQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":89917},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"3c93963a2b68208b839eae21c7d45b2115df73e0","gitHead":"34ea9eb70e1ac4dcfba4a8805be22b8776f119f9","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.7_1521461790209_0.5638257424683832","host":"s3://npm-registry-packages"}},"4.6.8":{"name":"kit-deploymentizer","version":"4.6.8","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.8","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"aaa2d9105affc125198e4313afca99d9466648af","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.8.tgz","fileCount":17,"integrity":"sha512-SAeL4TjWgc5R+rVaiGGok3AuHUvZaraaXsg47nrtl8nk90L3OiB3jDJ63pfLXnmW+9jXzL/gw2BWGCT0BUZVxA==","signatures":[{"sig":"MEUCIQCS6c7h3aCRcNb1rWcNAR683S23jkl9EIQvtQnTPDqv7wIgbEgTHHOO4xlOl/7B7+uaTgsP2gpMMqN6LILY5VgAgzg=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":89918},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"aaa2d9105affc125198e4313afca99d9466648af","gitHead":"c5ca99485a0ac99dc1e75c4d0e5670c457bd617c","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.8_1521469260225_0.01067271068097786","host":"s3://npm-registry-packages"}},"4.6.9":{"name":"kit-deploymentizer","version":"4.6.9","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.9","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"9f3a88d2c70ad3ca802c5ebeacb78f5b7d18dd57","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.9.tgz","fileCount":17,"integrity":"sha512-jrj0Tu8I3AbNb/l2vXQ6/Elz1HOKYOCHbcM2V6LcCL4QaBCOiLw5gW/4/F4c+8gpaVUKwC/aBRiA//wxQ+k1WA==","signatures":[{"sig":"MEQCIAl27p6lLHkz6H6qpa8RcoT/F0/0sIhGbq9VlZbCfGVPAiB4c/uVFwQVerJLA+ocIQ4XWelfaxh8kdt6OdvTUZUXxg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":90980},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"9f3a88d2c70ad3ca802c5ebeacb78f5b7d18dd57","gitHead":"ce3a46eb1259060fe07908f8743c1a540c223c3d","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.9_1521627686702_0.19759471936637363","host":"s3://npm-registry-packages"}},"4.6.10":{"name":"kit-deploymentizer","version":"4.6.10","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.10","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"bca73737b43b220f465ebd3ba97e98b5074b6e6b","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.10.tgz","fileCount":17,"integrity":"sha512-bSmsHlJXF2NduDsxN8iJRYmTquXm02KO2Ux5+lGuB8FDoaUDkXKobr4f2tXUi7GSxyNqIITxYNIH5O2i0CjWKw==","signatures":[{"sig":"MEYCIQD5WpjZU5AYpm+rIjlCNLzTxrQHE3xop77+nQLxei8G6wIhAIfdVb7KuKUFtht5iX+wEJ72Gqv4GBMiu0lSb31HgfT1","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":89919},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"bca73737b43b220f465ebd3ba97e98b5074b6e6b","gitHead":"c136849adeac21aa217d7215549cdd0468cab9e0","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.10_1521641173943_0.5832234913362839","host":"s3://npm-registry-packages"}},"4.6.11":{"name":"kit-deploymentizer","version":"4.6.11","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.11","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"bed786b9b09bd9dd5dd525e584d0c141f134b73c","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.11.tgz","fileCount":17,"integrity":"sha512-aVTNqfLm7HNTDsn4u9/n6Q+/l7nBGB5Cc6fEa69nZcZ5LoW6gOEmGsd3jn4gjc7NFxEzYtGfB5Kv/I6woKhsgw==","signatures":[{"sig":"MEUCIQCfKM8XQp9gjyD81li0PraUfluFd2hWnyCjKxCEFWnXcQIgWuL7IYke5T3waC6qf4HQgP/xAdpCkLZK1aAde+j61W4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93432},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"bed786b9b09bd9dd5dd525e584d0c141f134b73c","gitHead":"b6e3049a2eb637598d86778cb5630c94919e6b4c","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.11_1522833765138_0.45899180969124376","host":"s3://npm-registry-packages"}},"4.6.12":{"name":"kit-deploymentizer","version":"4.6.12","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.12","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"f0ffa683d49eaa3f69d58800351fa01bab257a88","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.12.tgz","fileCount":17,"integrity":"sha512-Pwl4Itc95FN4iClP0dtj0q86dWSD4GBTZrEzF3aFsneNwb02kpEfKDuPpB/ITzpJCKYRmaU8L93dYcDj3VUb7g==","signatures":[{"sig":"MEQCIE6WR5Q3zYB02iaH6RZ34ey713fev07LW7nPY9l9r57jAiA8na97+7pY+AKoWeNe4v6iRJ9TV9AAh0x4ZMWckO2Cfg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93636},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"f0ffa683d49eaa3f69d58800351fa01bab257a88","gitHead":"a04aab4275e69c423d5ec9a1008aeea3cb6f2b45","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.12_1523390735316_0.01313818108062148","host":"s3://npm-registry-packages"}},"4.6.13":{"name":"kit-deploymentizer","version":"4.6.13","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.13","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"2917053aac39790f3c471acb2461954121651d12","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.13.tgz","fileCount":17,"integrity":"sha512-465R+ItEmSKzk07xNnHGXMUJwbMSTzWKA8HNjGOagl4rGqnMIIzqsSzBSXb903/K2/MyAz+Kia81ZGeGUdvJYA==","signatures":[{"sig":"MEYCIQCSK7gCDF+i8UoTwAmCYuU9tz2A6HLg5Wv2tT+DWZMBRQIhAPmtZnm0POdg02I8NQqsPDeqQCsce/GOoC/uGSAzpDEF","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93706},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"2917053aac39790f3c471acb2461954121651d12","gitHead":"ec25a73b55d44ca6a6710e64a06ea5553d188693","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.13_1523452833533_0.5389667124460493","host":"s3://npm-registry-packages"}},"4.6.14":{"name":"kit-deploymentizer","version":"4.6.14","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.14","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"9de0c5f25021d8e80ddf742a3778dae201b7fb55","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.14.tgz","fileCount":17,"integrity":"sha512-9qVzPS4vDPDiSYuth1CyDRvDl2nJgbuvc3ej0yGzLizO0JPbeiNNuXFW/n/rAgyCXR4fC18VhAgtoO9KWleVOg==","signatures":[{"sig":"MEYCIQDjPJr4F71p7z0fn4+AP/OtkqGkzdjcw80vSuv7kQY0YgIhAKnKXF+jfiXLAr6cutCCTSTa/ElWJXSi4JhxOus/9tTh","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93770},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"9de0c5f25021d8e80ddf742a3778dae201b7fb55","gitHead":"a811b1178e81bef975ef62ccfa88f5769a445748","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.14_1523460190426_0.08761013429497533","host":"s3://npm-registry-packages"}},"4.6.16-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.16-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.16-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"effdf586a792ee024ea5d9ef3c490d89bbaeb047","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.16-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-nDtBm1ir6nIIWcakQ6W912b3XoUmd/GdWqpvzTzsJKiIHOFbmbEavPb0F/vM26gHOX9UGEWVBC4OH/40U6nWpA==","signatures":[{"sig":"MEUCIBeXa4cqAGaZXcxpy5QJc83nqYoLWNrN2xWI1REiTuK7AiEArsWbnrdI/EdyzyxuI04+K6WOEGc6/6LZ+K9IsvPH3CE=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94234},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"effdf586a792ee024ea5d9ef3c490d89bbaeb047","gitHead":"fab1fd39ab9a94c8ecc4cb5225e1c12116e47cb3","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.16-PRERELEASE-image-sha.0_1523461501422_0.3517180994371316","host":"s3://npm-registry-packages"}},"4.6.17-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.17-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.17-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"4c51ececb197d0b1ef4826d67eb94aec2a87b89e","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.17-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-gSQPl4O4fpiPES8S9EFJA6HjLL4EK8qXBAs3/OqFQ66LuRA7J2Q/zXRiYCP4OSO0suydndoQbLmSYf8ouLlMPg==","signatures":[{"sig":"MEUCIHJAj0mJodu6ZS3n2kKz+AYY9boXrv2T8QnDmwG2o9/tAiEAwwUjjAywwh6NcIUB4chw9uD7E5kAqhRQFCcqkhjBekk=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94353},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"4c51ececb197d0b1ef4826d67eb94aec2a87b89e","gitHead":"6a9897af1ed2901ce8fe818cb70e1fd85929221b","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.17-PRERELEASE-image-sha.0_1523464538789_0.41275973374071095","host":"s3://npm-registry-packages"}},"4.6.18-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.18-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.18-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7bf5f3e7b90b7416464737f9375d4de2a9b8639a","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.18-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-KS3RFdvoqe24vL5icMKvkeNKco6G0PycyN6vcGoF6z6X95k7cEIw3RaQwmfss9ujda7gChc2WJyjYuTj5Tspgg==","signatures":[{"sig":"MEYCIQDizuzhcLqgZyur4pzELAELeWPjfDBIptINsKD3A5rSKAIhAIA6F5MvrcEmLToDjBC2v9bGd98ryF8556klYARSt/Zo","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94427},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"7bf5f3e7b90b7416464737f9375d4de2a9b8639a","gitHead":"01a96734e4fb33f9c5ba32b20669215940be1dd1","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.18-PRERELEASE-image-sha.0_1523467089515_0.057247587505957265","host":"s3://npm-registry-packages"}},"4.6.19-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.19-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.19-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a97781078083dbcaab59a99072adc471c0ce1a91","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.19-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-oVdPINtJG/q+S4QQvgNs3JIc4DK7p0WS70j1CA6bi41oCZoLwgSzzqKYW7+yXh9V+iV0WmDCmcNifWBJeEVZpw==","signatures":[{"sig":"MEUCIAqCefxuiHp/Mw626BIETvOxV0mpVUBYUNB9vHWbPdH7AiEAwy12M9L45J1mOXUX3VkmOK0ipKpls9CChKGeHTi1Ox0=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94844},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"a97781078083dbcaab59a99072adc471c0ce1a91","gitHead":"90383257d486be597d72fc2bde32b21f34ea8c4e","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.19-PRERELEASE-image-sha.0_1523529617786_0.9681048408949304","host":"s3://npm-registry-packages"}},"4.6.20-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.20-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.20-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"e724c157823a1fd547516f225c0790ff35b387c3","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.20-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-P7ZACcb6mbvlt/bP5LHA7gXc0127jVoWdYOk27UqVT2zCx6/YJdijQ3NdRn3tzyItUpJwopKa4PCXBisc/HjkQ==","signatures":[{"sig":"MEYCIQCS7lFm9qwQeGxgQ58wdKt4KUAA4CoHwkK2ZUtAgCE8bQIhAOmXZz3kHE8v/cU8ebwHxLZD8+LfzYa4McMVU53+JqX6","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":95009},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"e724c157823a1fd547516f225c0790ff35b387c3","gitHead":"19e1ca3ef05c13fc1352c6127c754c6d46828988","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.20-PRERELEASE-image-sha.0_1523533277551_0.050123996944669624","host":"s3://npm-registry-packages"}},"4.6.21-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.21-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.21-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"1e676250c12f56cf16e2cbbbbd3656efd18d3455","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.21-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-uSVpMPvp7YGLMzPfDwXPhayuxnxd3KmZK2jKEo+HlRBgEND4L33Lk7B/w8mK457nBi2Xz3S8KNuxfM2VhOCAAA==","signatures":[{"sig":"MEUCIDo5ToM15XunrxtqalPZ9LYntAEPJtOUxiV+AHGloVnRAiEAvK0X0yWsCjrOkvl7o5Qusbn9NROeW96dcZ/SBaKsk9Q=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94734},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"1e676250c12f56cf16e2cbbbbd3656efd18d3455","gitHead":"665cd22120ee61e9df71372d95fd47d174983387","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.21-PRERELEASE-image-sha.0_1523621383834_0.9484771135284511","host":"s3://npm-registry-packages"}},"4.6.22-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.22-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.22-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"ddad7043ef7c678a500847296e2c2a24d4e5e3c6","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.22-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-+Ai1lQHuPdedSyMwuHrNeKPm/aIzugj1KxVFy5OsDYIFLORwLRSrVa4s85KPcGBIixW8ARNsTspW4tyov+EmZA==","signatures":[{"sig":"MEYCIQDsUiydSZizrqc9Zq/mtix4yOlxL4OtX5Iti8wFckKoaQIhAJmYrirDJeRRddWyXRGk7QRzE2GE5vxes0s8N7GqR9r+","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94359},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"ddad7043ef7c678a500847296e2c2a24d4e5e3c6","gitHead":"bb96eb37318a5e6923b1d4c02b49a102ab836d99","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.22-PRERELEASE-image-sha.0_1523626366903_0.5252311792353372","host":"s3://npm-registry-packages"}},"4.6.23-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.23-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.23-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"c323e9d649170927df5d288359a569e87ef6e60a","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.23-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-QTMMf+o0y9/NP6upHS0/1S3jbzKf7JahyI2zI3BBOcPzbcCwtXl9MI55/FgiOv4jmxDkc49m717K7JpezLuxhw==","signatures":[{"sig":"MEUCIQC0t2za3OzGSJA/JZ6GOmPBet/Qayby4iVPZjq5QcVYoQIgQTae3zbvQy2Nr4CdJt3Ea1E6rlTRwsUMWISKuJT6XZo=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94529},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"c323e9d649170927df5d288359a569e87ef6e60a","gitHead":"035345d6d9d42dfac5547fb2ec4dcc8f70b82d8e","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.23-PRERELEASE-image-sha.0_1523627497046_0.6713783108084979","host":"s3://npm-registry-packages"}},"4.6.24-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.24-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.24-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"c179e3119504ebd9bb53810f9b03e7d034052ac1","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.24-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-KEZYUuG6TDdBRBbVKrJqL31n0W8wGSJZdzO35PWMTDOntTmUbyQ12ofOE4eRXSR1NaJBIXEwQhyTzCFSAxlyvg==","signatures":[{"sig":"MEQCIFDA1SzGH9HVzEVpmkMgFLRFyEVZGSmbzezL5MCCz/skAiATausx9PAjBc+FB0VoYEOT0AzhzeZqvLfpcu93Lq5I2g==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94529},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"c179e3119504ebd9bb53810f9b03e7d034052ac1","gitHead":"e170fdcd30e057b9bc34ddb3450589f1ada846eb","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.24-PRERELEASE-image-sha.0_1523629727611_0.09297141937984454","host":"s3://npm-registry-packages"}},"4.6.25-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.25-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.25-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a4906f7c259dcbaac3560a096e114c13805f04ac","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.25-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-SoimeCJt6i7mu006tq7HI7B3CbMwBKCVbFurASzquZleaXM2ZxqKYC0ffbsDP+kNu+tCGgTL95lmSaE1O8Lr2w==","signatures":[{"sig":"MEYCIQDlGKOGGVpXLwG83IwTv5AqisTafU6S0QkerKeGoMJYuQIhAMK5DdLh79+DR8GXe1rgUgi9dUgnbKJLk5eVdA9VRsht","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94359},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"a4906f7c259dcbaac3560a096e114c13805f04ac","gitHead":"571242cd653cb136663ec1c91d51c4876a0cd1bc","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.25-PRERELEASE-image-sha.0_1523633633093_0.6833366890093633","host":"s3://npm-registry-packages"}},"4.6.26-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.26-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.26-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"d88d98d8c5c3eeda116be4a758d49eb6f4198f47","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.26-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-qKpERT/XiffT03Jq6iepA43kXXDC2uDEuMKPPq+7hRfxrQcPg2/4UJC34jjV4rxMXRjt7jtD0ybCPvjBFPxOFA==","signatures":[{"sig":"MEUCIBvZhJ9Szzq/8EyKF4AksCZIMYIRmtSCMidO6lTOaE50AiEA3C7x0D5TxdrkWemmJrYps1pYsQodC5f1zlIqHFAcjXU=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94268},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"d88d98d8c5c3eeda116be4a758d49eb6f4198f47","gitHead":"c44ceac55bae04b4a7dc761d5f2104441e6ecb2a","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.26-PRERELEASE-image-sha.0_1523633667205_0.25338217583331635","host":"s3://npm-registry-packages"}},"4.6.27-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.27-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.27-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"3798abe2a40e587d15d1207a9d1b5ae563e9d3c1","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.27-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-ndsDpzZ2JMsQBXMl8aujLU9Gv8KTNMiC8jBoSlhnPppK2WPhAvE0iYUKqen36FQMP7+3iDm2HIGgUJzPRMe/gQ==","signatures":[{"sig":"MEYCIQCkBXF/W33/2J679VHbe6dItuSqCkvPyjzr1ubt0L1YiwIhAMrhb7sH4aWl9Y2xGtNN8ErCkZJMCYfEPRuqjGJ88d1w","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94245},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"3798abe2a40e587d15d1207a9d1b5ae563e9d3c1","gitHead":"ccee0376d27e732c642fd33b9714a5268ec7041a","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.27-PRERELEASE-image-sha.0_1523635602464_0.3738910648327356","host":"s3://npm-registry-packages"}},"4.6.15":{"name":"kit-deploymentizer","version":"4.6.15","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.15","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"74da608bce4a45003eac44743b0835c372a1738d","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.15.tgz","fileCount":17,"integrity":"sha512-tXed4+Ze3r/IbLQWHJY+xZFCUuQJ/Y2Uaqdqqy3jgnqxWA5FKNBN7pLJ1rEPB7UmqGPY/sE9y2cuKfrpPeoiiA==","signatures":[{"sig":"MEYCIQDtsc09hMHmKtIz+2QJTTK46hn8E4dXUVI1akMrnJb8qwIhAIfGRORUuxsqddxE2LC4XFDlq4s2X7WFdoSdxIvdMjPQ","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94075,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1FcVCRA9TVsSAnZWagAA5xQP/2EheUbHYHmP7HATKdUw\nbSbHWCvX6675W4tXbmgiL0A0Kko/F0O5K8noS9s0nCGH5vxRuYQyaCzDL+1j\nPG10TzLjOVgc3DAL8kFUpz/IBPSIrPlrm3JXSjQcxl+DIKVZFLd/2kCd7Ngz\n9FQhk9cbdDnWewNv05j5M/EkLDy0+Id0KTmq7ZRmhuarXqvecjCNCOSSmTzL\nxJFuJr1xM/rMtQA6XXF9jKSqPgCWJV1w9QUHIV8JBNGteisHLOVWFDo/BtWG\ndG2HpmJ0q2YAJFg4wQn/F7l9C72O4lkeH73hDyurAB+pqiBBa5sxvTIIitXD\ngNSiX+z0TTJzKYpKcyMUjN8cnXtHYRgi32fR63mJzjDhOxEdKiDIoBPDPvMu\nrs5Xq3+7Jw7JkAyIApeSEFEFOcn52j/gYp+EckQAx7beqrXx2kParG6hGcrB\nKJ7sH6L6dbyoqQs1fuy2stI3LOq0g3+nkGtcgSdH+8676zU05NELdXkgVpLv\nUIBuLRxLGPebfBQlXzFjCJ9bnpRBl5JXmcRwCuUSz4ifE/lTTsAtFeQvfpN3\nwpEMLiCfhwLyY+rrZzdUVL7Dmqzh0ExhNRUxE+yuJLXE+AjIpJKg0OvMnZ4o\nK/rk3JuwqwyYOgK9XpZtxGDQ6JFMJSwpiDIkjNDOnktnurtEHMFphy2q6Ki6\nO7+/\r\n=9W95\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"74da608bce4a45003eac44743b0835c372a1738d","gitHead":"0e4c209a2a1494d30bb7967c8680ed360f2c7501","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.15_1523865363561_0.4150804636388199","host":"s3://npm-registry-packages"}},"4.6.28-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.28-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.28-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"6dc60eb488a45eb4567fd3a99516c26595f68621","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.28-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-dINk8qeDBJZBE40zk7VRDhS+8nAUx+XLS38kxOcc9OQf3xg7HV7SVmmAawslNnQBSegRTm0LzzQvjm1oNfVqUg==","signatures":[{"sig":"MEYCIQD351PkMzX3Jtwqr/w5wcJTKFi0YYghZDJGs9tIBroxUAIhAK/5qvYxicn9RfWaxXcqeA5Ci88TTauFTxCgr7zMsC9z","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94430,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1Gr6CRA9TVsSAnZWagAA5sQP/iKCFftmNV9NJyvYwGhl\nKKoS18k6FQl7wrcCCrUStC+6WRx5bdB+t7gY5JdpAdhzmU6PirfZD80Y0ETM\nE5TVXwCEHaRkNO+c5EB+QgI4bmW15XcGplQqX59Fp2gLiR6i+HiQyji5b48M\nAk5KSXj/xlR+ueiynaXyPYiV+U5j9yPtrfS1TO4ThkD7c1jMoIUyzwD68CKX\nkSINwvPSNO1cE6HzMa9YEu6cy4fjK5J9VCuI6HcJsGpJma+2yEvbnUlr1Afj\n8Qb+SL7u5tz8d4Hd3pPWh3dc/MeCw86glSBCZSTN8Yq+aKpQeWIBTAI2Xfcv\nvhBMC1Buc05+3nYCUU6R6+0LnRB/iZwS5/+wBq4W7JMg6u988vmwB84s4sUj\nMWMMK2/D1Hg8WF9QJ3n8l/a6CzcX9f+f2m6GKfvh5TQPy0yoIvQoCdo5dQK7\nBT2ES4aTop5PCfLF5xT+aSva3g/KR/laaRSFN6a8JCQsJPQSGkKrl3e4OKmF\nf3QdG3Hb0EzjSqy3Tnh7bqXR4Ez6m5LyBJyVKd75H5XwLP1hridlx2wgaoG4\nlGSi7HY3Wsq9nFfmEMMMyAvMfP5EXAqRdzag5npfDogqWQ8f5EO6T2aT9N+U\n4VK2F54DqSvTqTTYgwhUFl1yUR02PagUkDW6hNRbQiyjbjm5pE0iDrEoy0H4\neZjb\r\n=98HJ\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"6dc60eb488a45eb4567fd3a99516c26595f68621","gitHead":"c9b2b683d4b38754f46544e63ac443f2fa4d3ba7","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.28-PRERELEASE-image-sha.0_1523870457480_0.29173114363717234","host":"s3://npm-registry-packages"}},"4.6.29-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.29-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.29-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"09169a4e539a65e39fe414454ce5098b7042c95a","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.29-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-U8z5tcquQ9qxr3rp8aeyuceaYAz4IF9Wu0IZCY+42Qw/+r7DxSYxm4b9U/VPW1UCBvnK3vCSvdp/+3ZNUd1UZQ==","signatures":[{"sig":"MEUCIQC9UNUg2A+i8Rf7yq2095upEjZV4mMKu8wQkcbozzdZPQIgUCCV3vaQtZ29nv+PGIlqIjGDKzv+m2uGIAwe2MXVRQA=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94430,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1GsKCRA9TVsSAnZWagAAISgQAJeWyIZo4AIX4ACUeuiA\nPD+XbwasbamjZI/PFLFumj9PvUycWpR+E57RgdMlAO/qL1BabXH22FEoZnWY\nuIIWMfIQP+GIL1k74QTNpozYmo1kB7s+D9VgZAQ1bcByb7w7XOIjKK88/P5r\n57dLlm5+0Tl4uvP/wVDv6QTLQivKRlyJZ2U7j2gbcyUdjXCHV5NgRGjeEe7z\nu6CpCtI00V6Ha1iewXW0DitWUQxWgM19Y2ZVgPzAJlHkoxG0LCAUC6/uUW7s\nb9vCIjrP2vQDygDHUm9DaF+oJhLZ0MHJh0TXzMGoovh2D8cpt1XURO2xRCpN\nZ8aqd7guNToZ7ssVnXtuCdofgVe+GeOZ0QF7fKEkTaXSa3lYgKvwtdp6t3NJ\nqKT2Pg9/G2+aVIZs1FRUza4uYys7GBJFNlqOxLvL1PYFTxwJIoe/kpUhtmca\nlHq1OqbvtTJ9AzWnvUDxbN7E+tsJC6N2sIO05JAgxl5q0R37+xKy73yVzAAG\nPtFYM4iD//nEAzJ5L/J1OHhsIrrv8GmA02XKCFqSRPT73yzdo9C2OTNvGZIQ\nDyCn1GTZlYKqkwQn5lNyp1aw7htB9AvNn/8MBDRoQeYZrzawyCr8wqx8EPBO\n7Wr7KNgl84vuIPNh6Az/m6p1w6XUB+6bc/jrAzArCN098WDzXSi06BDVcW++\ncW9v\r\n=SdbW\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"09169a4e539a65e39fe414454ce5098b7042c95a","gitHead":"d8db316e3faa78c7275f20f77568859c05c605ae","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.29-PRERELEASE-image-sha.0_1523870473434_0.8212948976746735","host":"s3://npm-registry-packages"}},"4.6.30-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.30-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.30-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"50482ac09ed357b053c06d0aeac8afef67bed255","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.30-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-aO6DQPbpkOYFm3b76SDhMWYYMfeXQUOysHqnK7Ecw8uzcF5dVsyFP2PW0dmgJiEEn/hb7iDnd3ft/goHXnjdfA==","signatures":[{"sig":"MEUCIQDQEayKgpHwSz+OY+qj6yz9Rnb0udpSy9UEmszFWKbzwQIgKFsIJu6K6s5BMd1Cij4fbVOwsocVcyAWHAlEB8kcOwk=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":95058,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1IUcCRA9TVsSAnZWagAAId8P+weJBd59VNJ/uzKDYHIO\n8HE5uelAtVb0TGuTitcDZAVQFhdfrJRAf1WWAR1PPGB9ol5m3FJg2mRH1FaL\nBN28c90mWve3R6Tx5QDZRUICxquR5wsyKhr3LDo6nqo66P25Z5yijGYTYYeN\n+TbJWujOCpeuqmxgh55nzGdDHFywj4HRxxnMTLHMRf7asjIzlILbGsR48L9+\nRBkmpPyLx6vVAgoWbOHHFpqsYx/6Nt2R86NnakyQhdK4UcpE60DCksHw6vWg\ntikdnQlVAzWYmuCR768kujkxQpLqC0b4qcYjw1ZyMVjt+q+ndNiqsm5jZrWR\nYDiOCSw2zbPIFmAsvI2OF1TNcB6Z1xJ5cWbWms0sQ8a5OQGMNVaFZOrLX1WB\neuPiNFEiFQH891FOPL1hBKDc8l96IpiDMvBD7PJICt3lM1nfUzVvQMA8en6c\n3V/Fj1vfW5rCl6glUaSECcnai0I4DauMEVdHgAy5dZihVYv7dgPlVt/zlqEY\nw4LtKRMOQ58+E0FEyP5B9rJBg6SF2wpswFoKT6e1FkkWa+ODO2COWLlkJWbn\nTjAC8yHTHRj9QDNVcBg5KP7Pkx7rQfFWdBy8wSKeaV7Ebc6h9DTSvyBocGga\nbysCPlT2iH+2XzLlSTnb54l/CoPQanjCEsfMGJ04zYEheCxAxTAPl/VKdokU\ngZmd\r\n=D4eL\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"50482ac09ed357b053c06d0aeac8afef67bed255","gitHead":"5fdd14afa87aef120489c48fdc739508f15bbf28","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.30-PRERELEASE-image-sha.0_1523877148260_0.6150429774266679","host":"s3://npm-registry-packages"}},"4.6.31-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.31-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.31-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"d0ede33b67d204cfa26aa8cd825bd7ccbd056bd7","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.31-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-gRBpvQZalDX0TpsqJ1KRcEtvFXhwYvwt/Ayg5ABCnThpeBBZCAK/Gz0hn4l3TJfmXbKVtIC4F10DvE1IzPyIxQ==","signatures":[{"sig":"MEUCIH1wq0UwRwF6Z2sWF6i5sii1L1d4Oagwsyb8FnjBSp6pAiEArSN1OZuqxvvO1cDUZWeVh3/d1XCGo2RvSn75NyppOTk=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":95095,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1IwlCRA9TVsSAnZWagAAxTQP/j8CJ4Iy+uA2feU/7jCy\nJiIYSu1q+LqqpvSY40t7k5ZmkrnTGH9OCiSEVEkur6PASkxS5ZkgznEMW6fK\njJ8ffU6txXz9hfFGuWVyKxX7p31rvKDeP3xn99zKNQO/l5qyOyJBnscF6Y0a\nlMxIuqL5UolJYel1xqoL6+KriLL8kdhZtvTL0LYkSXuaHwBvph+b4qB8hmRO\nRZCIuHXFXZYQHtnPBEmUbrCZI3ajWMZNnlXljXrIi0dZ84gcArRW/D6z3Etv\nTX0BOS62tM+zn+O3EWex4BA3vGIwZqYcDW6cg2pclgZMp4fKeAu5+d+SJJrp\nFcCp1X1RJBq7tO2YXrMo5fokxz0pRrwkgeFF/xZeq32EiTvQH/ecqm1cej0R\nAzu94SvTMQ87blfKbBLTBxJ4HNeU42CL6T4Ig9bXTLQohoyYZSFJpNDBN68k\n6r8/87KfNUR/pwrFO19d+bzsGi6SQtIu749L2zhR3hfI88o/C0bH0hW7YhHW\nOE62iHKiJqkc2jJOZXfMSrKIlZPNsVgPGYvI/wvxSh/vWx9WaRJA5bksxut5\nmI0SWWFAxFKQCmDHtiybVigDZfH37TalUnaY9r7Y75r1+E0KnrBJut/jNtPq\nvknABW+aTNx475//QyjUcgD6evOsywWPek8JaEI6HwsbX+OYMtRpN6tyI7SH\nVYVC\r\n=2KAW\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"d0ede33b67d204cfa26aa8cd825bd7ccbd056bd7","gitHead":"fc0d6f6bbcc6aeb11a393a3c676a2bf9ae2cda09","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.31-PRERELEASE-image-sha.0_1523878948210_0.12544647398515685","host":"s3://npm-registry-packages"}},"4.6.32-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.32-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.32-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7c5adf5e1e528a840ae0c7f8eaf37afd4263dc01","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.32-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-AUSQx+CDvuNuxDI8JoyPVaSjXPgNbiJiQ7IWL1FPvmO8RX7vbh9w2NKPhkWcCV+PJhf2VQjNFyrd6I+8VXi9lw==","signatures":[{"sig":"MEUCIQDFVg64N03rLpPCYt+/dbavu80J5SUTixfo71Jj6kLfywIgGKKe5hIbn2HkowzFx73pbnQ4gpmn3wVPlq340riED2A=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":95091,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1IyFCRA9TVsSAnZWagAA42kP/3lgY6DSsm5PaBCtbU/j\nuTXozSNWTuh3KX8PBjhEy04go4tcACi/hUYwOvbsefIDzdqyhRu/DZ3jwEIa\nYcP9Y7dx1So/sOInR4G4gQA2jEgNSbQ5VcUao4U6/WMKQiZ9CErHuOePDe0j\neFXq0vhivx9MfoF8o+F85ZPtUV7/TsKtkmxWzUjUxwUeQ8X2/Clg7af0dJKY\nbl9T8+tuZp1BKI/0MOV5GekpsSSks6fA1SCdD9opB1wXJjmn1J4K6i6LTBqx\nbejIK8EbsteW/lspVOOAyfCNFSCp0V351bryJV41l3RNblFkFaZtVsrK/cIY\nhSrXgeGGEtXXb52tnOYuw6cgDkSkgrBCIUuhjsKlYuvdx8gxJl0iOclIaL8+\npi4SOnLwyGXii2PGgjd/jcXfT8ytvp3Lai0JGlEvUKHk3GrWq8ke194ChfU0\nE2ERJgw+gWtRcsDpXIZzkDu/pO9Bbo5UHLBVw4JM8UKhnGP7l9VDI7QkSAL0\nXbS5AEwQ2/DvrAl86+EQUN7uv1hfUvNKKs7V+m93YotNLje2Gp7OZz0rNfOw\nrCDIz8mi7WgQuC3J7xgIhdOmOycLiEb3RnTPQYFpe8FfjAvvwr0OU0yhy34o\nAqL9uggWlwngEmkZeBBRvA32e9fBAgNs9gSu19lBSRNQZvvMW7LaD2Zxjg8X\nNFNy\r\n=b+1r\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"7c5adf5e1e528a840ae0c7f8eaf37afd4263dc01","gitHead":"6d52f8dcb7670dba579cfcac42e2a9282ea65762","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.32-PRERELEASE-image-sha.0_1523879044337_0.14495098849182098","host":"s3://npm-registry-packages"}},"4.6.16":{"name":"kit-deploymentizer","version":"4.6.16","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.16","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"767da52c2ed5881ee69e36f80c1db88075b0b23a","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.16.tgz","fileCount":17,"integrity":"sha512-tkk27ZMKF9ASacEDDh5juZxfPazxgulINPBD2GOty5wJO19ZacuAjRg+1ut0A79yEtftttYYchyBL7VH9dgFhA==","signatures":[{"sig":"MEUCIQCAl1AybT2mh59HbfOvav7j4zrfYcyLvduQVlhUl71eAQIgRa73omUpveWhpX/hPZaKrgQKEv+OjD/HvsG52mnlrzA=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94075,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1M3qCRA9TVsSAnZWagAAzPYP/3ByoNs8g9QLIIZsOYKM\nAWrkDBQN/FLFUgfE4H7bv1zs9AmfrRDvUyJ/R0SvfSyFzc+pqBQF7cabbGUc\nTanvPGu0pGnnD06qTNAA1efcXq7dDsSZp+kDtfoDa7tzssLabaXe2FPP7U9N\nTa69QPz+ptYc8ZONF/ggLCT7IUmW/1H63jAf6/YrMPFrkNzr4OwePO5Rp6g1\n3ez7c+BAf2d72gX3dh9nS713j+z28fF9v977driIirfZOCp1EylT/GIZda0z\nvZUeqL82ZjxMx/1/mbvaNqB+/uTq5tYGdt9p8iUTLRqcMil7PD+a5RKkMdoQ\nJKA7RL+Yom6Ms5JKq5JWehaeTvIw1H0o+26tqqLDeb89KMxk6olpkfguInHA\nBeGg6xv736R3QGvIi6rI/UX0f1A6wA4p8ALgfyC8F3HhCzlatIHN1+e4+5GS\n8MG5NdHvEMLzX8RT2H8X+cpYuptPkNfuDwfhmO9RSDk7G2fXfH9G4XNinAo1\nljzACmVtZjd+R8HggSwrTi9K8uKowVOYoCEUJsfiMnhP5mgmF/YixF5FjONr\nD1mE03j+VPY4b7XijWdU9snZ2ekXw1kPTCek64H8Vfop1GcHD9cXGudgbwZx\n7aKVok+6Bnb2wv9MvfZvYCvVZCiCu5fVrdOUeOgCMP5mLaKAH5oG1Ea0N0EZ\nfHEq\r\n=qMWt\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"767da52c2ed5881ee69e36f80c1db88075b0b23a","gitHead":"5f2d41da84e177653ffebab8d3a41c9149e42b6a","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.16_1523895785268_0.7450633067793413","host":"s3://npm-registry-packages"}},"4.6.33-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.33-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.33-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"ff3fbde63eaf205de4677dccbba5e9786a04bfb3","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.33-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-ck7GtMwikO/zNcDHXe7EU3kQoth8Kg26sOdSn08fV/ZRNGKMPVg/Qh3TDLaSuXX8GCL4uuV1HzHVRG+k5R1SEw==","signatures":[{"sig":"MEQCIHU3rS2t4AoH8gUxTV6CJ5uim1EJr3WLz7EaWzSymduCAiB2xDLhlJbYTugjqsGg4a3GYbSS+DGx5p/UlIxsaWHjhQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":95091,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1NkjCRA9TVsSAnZWagAAUt0P/jLh5h1S3uVa0LZBuYBV\nNG0cyRkR//9d/QsYjb20IcVENYz2mpYOz1bONtjMe2zHolRCjMZ9GJKR0C7X\nsSoDLiWrZVREFW1aclM+K1NpvifaSfIrIrTDJLQf5RBplG1rKrjtZuQtHoKx\nm2EyxDmWYhpZbjauz4z+vwPT5OqcVr7jVouy9QkHFABx9BV1BOIFRZvi2/6a\nWrMLLm+eh0BigUSpt/zKAV+S/R5KKuaQVd8MJEyZ26i/wMSrYtj287zTl/YL\nBZaZXs6Ylo//LXMlC4PuIsaA6lQcusn/Yl3dBSHlp1EUNNNOQX01D8j/2Dtj\nnR2SVW/yETDPgxjG3Qr49ImFNXdeUX6pD3xN6if4xkQymC3J7wgMas9xsE5U\ncusABzw+CQRur3nIU0IPi/lD9HTzdHGp/c4jShbBl5Z3+VUV1jBJ0sBAOKsI\nWOyuNJ8vt1Mg2wJRVfZVpjIWHKtGO0hj7BgMKwO3x/EqJPMPHdsbnSdRhVv3\n1guyqA7VW9URECTDIT1UR153ho6yzsnys4MERstmqBmTDwAJjCAnd8Fadwlc\n3Fae3UHb+hFFe0n9S5p6nwK/8upqPPb1I0IoDbJRi+AQTxfQ8qy55ONmg/D+\n91SyPDJVHjpojkq4fMeirapcs7OKKpxdaP4nq5lHK2kId9ile06Pr5ClctLa\nQKfU\r\n=Z2GS\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"ff3fbde63eaf205de4677dccbba5e9786a04bfb3","gitHead":"d3fbe82b7acb8a1a6f0c1213c6e099f138b93c6e","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.33-PRERELEASE-image-sha.0_1523898651535_0.40818370763442346","host":"s3://npm-registry-packages"}},"4.6.17":{"name":"kit-deploymentizer","version":"4.6.17","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.17","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"bfc0312f872170dbfbd9e7aa987fb4f6af3c8b84","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.17.tgz","fileCount":17,"integrity":"sha512-qrlMNl0j9BLsWJANOh7DZ7vFYvbdTg7sM0LspRBlnfDj4IAYgg6qRDkhllmb/i58UiEofFhZPAnx3BSopb5eDA==","signatures":[{"sig":"MEUCIQC6R6WyXfXMBF+OU6iPfR5p25wbVQk3QbeFYljo9f3j7AIgPEKoapnzATHLjfk/An5OHEmUPy4HhHNVIDVMBVC/o8o=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94921,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1PUMCRA9TVsSAnZWagAA1N4P/3jEPXP+xYMGHhrgfyrv\n7BEASOfRA93DigKXz/65ylszOvoHU5PHXgGUQ0gsTC0nfp51KWL7N8DfhXyh\ngUNwpL27Dtpx3w8DaFetl7mJG3QCl00GP186ay1s46YWUHUwgLi0KYk9J4Fn\ntciENOsiUd9+DrUoM5g4PaVhHF9dgPynWvRKuX1PVbq7LxUhqQ6JZml2+MPk\nU6CF0voyXJw60bMnqQJl21VwqRpyYL78QygED5gXKluyHmaN1wUWAjQKwljV\n3++1iKZERUryTkb7ln6RKJQL4uK+UbawWb9T9i65hF9FKDnDPGYFvedca/6t\n8WLeKJRA38wfBpdBlQ9UmMGg8O1Tu6h1vwuLLoT0wtJ7nM40Q76A4D3ibijl\nfApX04ph5f9o36FeXA22f+zy9CVjeMu06QeFmtIwt+101jeDjeThyn56/oD0\nGtdRgosdZlI2/lcq2pxV7LLbsBudNZRtxZ/LyfrtHLjfoWyzjdC+d42lt5GW\nZpvbzIvAHU5GuRnIfCGlfKHCvM/TMxpzG8G9MB7r+CjkPdso//2AiErnS0sZ\nbNCtOBzCbzCyl3spJB10L9BA8ynrJx9p+ELWyJNwEVSQQBtafwR4gEif7Tsp\nkdk+HTfc7V2rliEW/E31y6cDff/plgR4KgIWL98+gdv3bVB0lnlwy5y+t7mC\n/VpB\r\n=oxcg\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"bfc0312f872170dbfbd9e7aa987fb4f6af3c8b84","gitHead":"16b9b36e080c5b2cb551442d518788635ca9d41e","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.17_1523905802891_0.257890637426468","host":"s3://npm-registry-packages"}},"4.6.34-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.34-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.34-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"d38c2d7ebe9fe306c697000e9b5918364978236e","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.34-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-vDPR+cE401Rpw3uQdRK95LZhtQ0Up+gDxWoflvrkywGpUEUF2Mn5q4BljPbmjXDr6gYBE7Acjdcb+CH2wIzNow==","signatures":[{"sig":"MEYCIQDkym9ec230SdduUJGChQjPmZtYTeAdYtXPTW66DEeWywIhAIa7keZ/5YQdRFyr3emuf0iDC47iancy0T3QzNFQT7GK","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94811,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1QF7CRA9TVsSAnZWagAAghIQAJQzGIXKgedZzvQ5CvhL\ngusgy6RoVI5ZqetOLvorzsAK4WP1tk9zm4q6sWfBHR1pRwBiS/ySmM+7E4Hj\n4cOyEtdTWE3QDQhGrQE7RIYIBRQqQyeKhlJABySC9b0IwlHn2VLNltGf62eH\nTr3S7MPEu7JlDMkr2lfY/WuDNO9o+8Sn0bi/zQtTRCzNwcm/cRSVehom7W73\nsxEq0K2uE2yMUO3nLauYyYWkxmA7/P00iKPYb37x54ENQVdAN6vp7kPU3XVV\nHHS3mqv1tS30SeLION0Vsv3ERdZfe+i3wqnRf2Xff8KZMw3k7sFQ4zvWSnJA\niGzheu6iWEH7I9Ld70pBUvErlu5YcrBOm+Y7zOrVslnA8jUgQzcaCD7s/7Ah\n8ADsU3sKpM3LSvUakPnGHcY+bKcvBJNpz5WUQzjJBprjzkEvKfQFlxHnlSVD\nBpcRiWUm3Z0gnvVuCwLqM+69WvCTAJ/bynXJuk5XNZ+fvZeNGEkfaFVDydCO\n3Kw7nnZv88IbW6Cx6kjJR4QM9eJVjhBQQmglbZKkd46BbTzlu7hRTXpXA0yM\njGL7+qhm/iYpZgBvlTOk1Wp4TYdlzQraVGabohUxvHJcpgJfZQBc5j2WFXZs\n9JInKzwpOjXr9+TgofovoHzh6gdjJGwYZ3G+MDwCirkjO3G88x+uPmPOU9i/\nB8R/\r\n=96gS\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"d38c2d7ebe9fe306c697000e9b5918364978236e","gitHead":"3fb183ecc96a707089cde552dd3c099517212613","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.34-PRERELEASE-image-sha.0_1523908987192_0.5982438759365813","host":"s3://npm-registry-packages"}},"4.6.18":{"name":"kit-deploymentizer","version":"4.6.18","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.18","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"2ac200e7ed424f4618adc73fc63536ace6183dbd","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.18.tgz","fileCount":17,"integrity":"sha512-+V/oW6so4CoO90MnfCZoIQo80gsFe42NqIrvhRsIsLbxS9DB92UvG6HF76EC0DwAJtSATR7lxXotrUo5h2nD8w==","signatures":[{"sig":"MEUCIQD4NaufSkwCACGEXWeWW+aYUREfHeExN+6Av+nbIO5PAwIgfN+M9Td+1lJMXMJbreefP+UOSwJwiv3AhawG1G6u+y4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94641,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1QHmCRA9TVsSAnZWagAAvGAP/1iEv7B9FqCyqsh2sB7Z\nD05RSR/Ny0EWGdxcw+1M3KXH7vbF/ztDN7DYdF2NKI0HFSrGgZnvTEh8oBGm\nMiqCY7uPdeQ7JzmU5fhOCYJN/WYwtDuUWTFaKCEyh41Xq0tnL2RtUZ6P/vG4\nXXuv+d1jfZqh5QSrGgeTmD6SnIPkszCXaQSXsiFtZiE+Nfkr9WXo/5KlLXC5\nOe33MmYddc2p/DKicxAlLhAQKbgjyB6zhPKb9bTgKZw2qscO+bQtaD1WmAkR\ngXniTjNFbKZk3BlOT9OT1E79Ply8+yaTW8uTF59YAsc76ipk77rq1Gasymcb\nCrpM0MLgKSuZJP1zokqCMGnAbEhIG80J3lJ5CDGhSKGNKq6XLiFg8h05RRpA\nGYy2/3OiVAygnXEYG3WULFpf6THgNJY1zZZN8aAYkAdSUpctWMAn4zsECtTK\n57aSVdnEtAyeToSG33b+ltdy4dyL0GGrD+IhRZ4Lsqlt65p0v6oBE7kSsLFz\nirSUHi/f7QWN9OY3ThP3IG2fbLFjJqg7lCa2qFkIFvnR8gAZV0Sv4bwgDah7\n4LUa4C2+HX8fmUQadBlQAeuIfxSTD8mEoJqroxswRgmickHp+mSIBWlEQtSA\nMXnLSWS0f4yCyWDcudmUOYvJDNW3WifapY9wSiMGGB/5IRKLDvFUwi+6mPdU\nGLsc\r\n=y10d\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"2ac200e7ed424f4618adc73fc63536ace6183dbd","gitHead":"ed4d0fc048d0f0e3fbda89e38850f70216063428","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.18_1523909092607_0.6059993609359304","host":"s3://npm-registry-packages"}},"4.6.35-PRERELEASE-image-sha.0":{"name":"kit-deploymentizer","version":"4.6.35-PRERELEASE-image-sha.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.35-PRERELEASE-image-sha.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"1839dc0bf9e4e51e3dd58ea8f2d88b6e299c7e98","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.35-PRERELEASE-image-sha.0.tgz","fileCount":17,"integrity":"sha512-+2Bawy3GKT09kVWVaMSo8A04h1mIfp1iirBt/IvivcwY31MT7PxWiwVa/mi1iSaX3J4r7Vbz8bL6r+BzJ7MrwA==","signatures":[{"sig":"MEQCIBTwXgcHHKBzcBly5LzUFFzN7cE+9UhOFCV4It5CevgKAiBfO69436X6Dw5HVUABob/t6i0jVK0+iJIEUBWaLCDwvg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94983,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1dTBCRA9TVsSAnZWagAAcNAP/0ERj82HsWsSBYNUOz56\nP2/oDgxuLnMxK5r15MoCeJYYmsOO1mP4MXgeKP1cqTi6qHXDCfc3hd9hurhO\nQN2tGud6KL4zYGt4akreXdxVZ66/HkpgXk8OTwdDhIHVJ+tPn/nMVhjthg6A\neeCxMG0lgZh4VGcSurx2wAOFbJjXAGVVNHIwHRoXfrc+ccNqjU6OTqr1ms9a\nNZM8WeRJxcFGmRY1DGvas1+oNwgFGNzyumg+K8TNHGTNZIC+zCfFHsqYxraF\n/8LvDYlaBBgJPKc1fuAt/cmc2KtOhnp7h0752GgEVYVV0K4rIX77Xf1S5VTZ\nOrRAtqriU/IQhO5Oss/SujqeOdadT2TcjTERSpWhFmJma/B8uoke21ho/DN3\nK7ZOBEgBHe3EfDBs1uAsn0/lJMeDerY6hfTcbZuIMqHSzk0xZjktnkdNCEXA\nF8fNG7eexMKXy9fOuE5fuvnQD3Uv2sRwt+xYohn+roIdOeKH1PyZrILtN9BO\npWh8fkgfKG9x9qegG53hmoB3qgtrWpljhigIcomjzg2xHsohOF61XonuAD6A\nfi8yL9KZAhIkHhZpkJMzRBuLDJUoXeB+IIy/TVLQJGxq1zWFVkzE/cBuggw+\nSPxOZU+gins9Gt0Zgw3Ee2Pvct22YbqqVXcVLe+IM7g/xUiM/u2cINAj/jVh\njKr1\r\n=T0yr\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"1839dc0bf9e4e51e3dd58ea8f2d88b6e299c7e98","gitHead":"b6b02ca827de9d9f3dc354c2642daa8b7d535910","release":{"fallbackTags":{"PRERELEASE-image-sha":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-image-sha"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.35-PRERELEASE-image-sha.0_1523963072297_0.13957280381006432","host":"s3://npm-registry-packages"}},"4.6.19":{"name":"kit-deploymentizer","version":"4.6.19","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.19","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a45762445828d507684bdef0c738f356f28e1056","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.19.tgz","fileCount":17,"integrity":"sha512-Pd1Yl11XzJ1PQVr68Zl9z+WJK/ngcIAIYG+7e9KJkHJDNdvNDB692W1uTcWtaDZiatD/SkPqJaM+tSx0wkF6+w==","signatures":[{"sig":"MEUCIQCfDgQ2D+4f5jMYjBayoTj3z6nuOeyKCTrP4L9TVXHYOwIgH2cxsXnACs8KPFAcHx0gXHJgiC+dHgdAVXSJPfBoJv4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":94813,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1hUDCRA9TVsSAnZWagAAtdkP/3obgEnfecbEhLAwqxMa\nFndBqCeMgTok6p6KrGnJmghiKq2a6WEjzmrUUUsBR5MLhHEefnfO7b1JfsJB\nOqFs6HTMqsuFLKFLQ9Hb23oG73iZX8NRcRanU+UnIKjYW7XxPTNe+78ZSahQ\nkKvJYO+owGdPjH6PnwmwTgNdjL10a81h7qDqYF4w4ZtbsPQewSYyHJpU5Dyr\nV0/p7THBWHdxTYMsHvaIKyUK2Pmh+1jp4Abr5o39pdo+FK9/ZNcBlJISV2vp\nw3kgMCuo5ibptYWPNv8ckv5SknA/37GpcmWyild9E8Di6siHcgs/dUsBU8zg\nLNehobxXlyJL0nhrjLIXobdf2j5fxOnfngw6ls8S9F3DRfVonTQIcjcBmIdh\nycdo3MElvBVOD6a7D+p1g7O3Vu6S59YSGaAuVCBntyTnvNKOFWv+nPJdDA3Q\nfRLNBrJ+HuKd6zXPcKJXYOcGw9hH6z3/Ko1Pj62aw5hqN+6lz03UiDfMcYbx\nJcwqd9EcLaNRVByZTK3aYiPKUJESZZcFyX4tUwA/njd6aPI7g+2w0+39S2OX\nn4174e1TJZdJhJnn84TIq+vHF9ir2hRAP8HtQAC6b+Qhuf7NuSwjczluosFe\nG2ZZCXB7Xwhbex/orQYTYO2SoYPeOfqJbeJluSrn/+zWlU0VhH5bDf3e3KHb\nbV7b\r\n=eLrG\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a45762445828d507684bdef0c738f356f28e1056","gitHead":"f28a687074f08a93d9ccdcb1eccbdc55bafe9973","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.19_1523979522127_0.7404815289777302","host":"s3://npm-registry-packages"}},"4.6.21-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.21-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.21-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"222e8703e6115ea884236a155502891d16a29df1","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.21-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-oQiRhczTL3p8ulrjvjd3Ux1L4KKDuwtmuJGT3edaD0yYpkgaGsKF6FQvnoZ8MwWQJzf5YfDdG3S2XqZRCuR1wA==","signatures":[{"sig":"MEUCIHBP4UCDO0fmXbf+itst7MtrrrMFFy1HP9Q0FD9D1d2DAiEAtaeae8E0LmDM4up6tuBmv+27701iLIjONQvlRU6VCSw=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96447,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa6ve7CRA9TVsSAnZWagAAhfIQAJmi1PZdcG3EMIXpeUz6\n/PPq/qRA1mmdMHVV/gDD8tb5PRZUPu6Q0mJWFC7MaBV7ILU2dg3QbYHQ/crU\n2j+x5WEPsh7j1iMXBNP6CCeFnxhn+hY06rTd4+PqSIuDWVezsxEGE0QSTJUx\nAGJmp2iDdyEmtVQw6MLNzmyVhgypSLnKYoNamgOWQhRzZGeoYFmUMj9fGwql\n+WfmHqNTlh+rH0PxXT8Isi/f8U20AD3BbQlJ/JFbimbMPxvSDpwpCrsjaFzi\nsUxopbO+6cwByQGxORUlIEujR/dVK0tx+IsCgtfU2GMxT0wvvy9KIfuifyFl\nIgqDjBS7zFYEwlmSf8meh9JUNm0ZVepgYUEgnQ1eorCIS2S1B0MN+06NFCIK\n4xerOT18oNHFjfg4yLu1CdH/RKQhAokI9YEu4FmFkd9IuomKIuBDblg7WQ0a\niqM6OGPM/zdsLq4Ux0dV1UdYtuJsCBB1iyrP+Ts3b4edyP4VEfjimqLOdUhi\n3OFMv36cZOoIO9QuzgNGMJrXtMIWNXBaCBctphebSgXd0QCgQ/DX0PNTrKRX\nY1v6XAwfAK/5E0lDWSU79lRFQu2/idSQtRVxwMKB2dtsbPCmR5xcRlrWmwQ3\nsUJskxjtG64AkuH8OFi2QxFesLvSbM3IsuJ2UxUrThgOoLcPwZOR4+r0FE9R\n4jgO\r\n=cMh8\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"222e8703e6115ea884236a155502891d16a29df1","gitHead":"891f1e15c5b0aaf4f2f49c0fdf8c320f6b52c776","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.21-PRERELEASE-envs-206.0_1525348282468_0.41668450452100525","host":"s3://npm-registry-packages"}},"4.6.22-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.22-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.22-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"378ae0a08e3623e1a1cc8153fddadce4b551c0f4","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.22-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-pSSOzWxxg5zT11EMmggYUGPUhKpea2P4dafHYkK8hL508HPT9XDqIEM/O34FMh8Ez+JixcZ82ERckDjzXxUhzQ==","signatures":[{"sig":"MEYCIQDYoFoDG9EsTvpzZRu+irGdUEayB8qaNeTiVKCj51D63QIhAIinhTvfWD+1AsFvA0yEiD8/ZUwjJGl3GOobCLT9cPQG","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96479,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa6vjMCRA9TVsSAnZWagAAmA8QAIFrC/CgZoWqy7GZTXJi\niXoME4eR0/ovLkzW/du2ONoPDZmL5ZFeUw1TLmfIJdBHO7k5YxVJIr+7qLV6\nWD1m/wkYYmSXQqNn2s9TwNsGUt1g+bF71X3v7QG28VvV0dm0ezyHjMC1yKQS\nL2jvhs0H6Xuf9kUyBK8GPcR2PQEDQ8Hr2FlTwqWoXUd5Sbn3FGzxWT2Y6Cp+\nL+dLTtsEBHVR+BOv2b9uPO/yWMsKGh7iPHZhQE3sdPPWQ4TdZf1o5K1/reB5\nE07GNqEssBBXXKr333/3yYh9wEekct1UiJde3DvGKuWP2UXu3CtRsGw5xupt\nib2G4rx5UrL2ljoWDkpoPuuMuDVbstf1d9E+ww0qb8ZWILI+o4H03Z2SOUH6\nSyL07u3cddp/FuaUVx2VmCfp6pht0sZtRIFwGD4oPunjHatVK+wUJMrsbG0l\nqwc0na1mO5NNGHaEVY6AKawvLZ5NjXZtkY5xNxaoEmODuYfwISE20phvVZnr\n/Y86OWVWgbLwJkF4OcUUJIeGm5JPUcPiObF0NRN5tYihxGRL3nTpLMtFn3Ep\nfinlWruLC5+ZUqdIV8ZbxE1Td3zgbSn+weItJ6BN9PInktkbIQn5TtR7iPKE\nF7WdK4qyVGEdHMdteZSwN4e2mTe+gwEIZxRfaQqrJbRyFLctECSGQrAzGtDZ\n5Q3s\r\n=jtPo\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"378ae0a08e3623e1a1cc8153fddadce4b551c0f4","gitHead":"1059b771b64f9566ecade4d9f6d1d545ed0a0275","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.22-PRERELEASE-envs-206.0_1525348555947_0.6404612753872119","host":"s3://npm-registry-packages"}},"4.6.23-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.23-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.23-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7808b4a6c80a8d24888f61a8cbc6195a846a69d0","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.23-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-tfBtYG97FGx+mBBgjgVZ0B1VRLnWx+TTEzGRJQTRmFS8ogOuMAiByJq8yvr/Ne1vEfa5Nu/lYDM3TypKg4vJYw==","signatures":[{"sig":"MEYCIQCJ4rbpBNWpYpzpS5/pVYWL0D3xkyxTgrF+tPVhZGhlCwIhAN7eSqhuiQHTVnnCi1vCJmMX2h89vPVJl4HmyL/bvTQC","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96473,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa6w/UCRA9TVsSAnZWagAA8sEP/i9XSFFfVnXifSYJmeLd\ns+UVVqMB4iApU4svZS3Rot37S33ICgTPeE2Okef2HF+5XnVNenLKjmmCIluU\n5DHLOl/KjpGP3C0GAPILW78XNTm0OLuLSbqJApol7et2pvgJc1+3Om4ESS6a\ngOHmP7V8uqq+CYeFRpwsPm9wGJxAHi+okL//Spga7rJFMvxLziUygRIcvKnY\nHxLBbiU9pshjWa5JFYSx3bCxR7qEG/FKofxLqYjbJQI4ME21dOGDDD66e1p6\nMN10MjqKHBfncDWXnCmIIqj0+iG6y5McuAczlq+VmrbE8lGrP0FxKUEk5JM7\nUhHl4py6ZOkBHi6Mv+L6gXpHVP9/djBi2jbL3np/gGirXVPPHmC4kfDKwhCP\n3c/4Q4mGYJ4hvNfHpytAiZlqkTF5UGhe0dQV1MqZsXi9KdHnhLeF9cvLT5fz\nUA+a9GdxuRegeOnc4Zq07cfN6+EiZzSwvvI9YMGeLOTicj4ZI4MOo4Z3Wzy4\nd0mYI6JjlcVYoD57YFTV50RdFCPqp+y0CgCwRJ+neT2bDSOBEyC6MQVqsxew\nmJvCZBav6z5H95V5hSZT85bM8P83pfLXcvbo17wvLrL9yPBGsF2y4LUy7N//\nkhDsB0ENIHLhf/Jc3zShcpAWIzMfLIZPUzjw7lDHF1h54rHf01+MVDBXwixj\nqQro\r\n=8Ezw\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"7808b4a6c80a8d24888f61a8cbc6195a846a69d0","gitHead":"900133a24b00c51678e41ecd1a53754a2d9c4509","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.23-PRERELEASE-envs-206.0_1525354451788_0.44336508221307325","host":"s3://npm-registry-packages"}},"4.6.24-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.24-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.24-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"94137e65c28e443f49cfeee6be1708ba3c41aef5","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.24-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-unqC2SNYJRHkcXfHVBIifxg0YPxm6yyvfwkgGA0jVbVgC6D72xr7PJdTLaXu11GpXw9x+W/EzsrE5XEJMA6ong==","signatures":[{"sig":"MEUCIQD8FJBCYLagMf1g1PdPzYLnA4YOTVzfxf8BP40BfuOOxwIgH/JPlz8nlug6HpFR5cJWEyNjLdj54zW57rkxQ6FEQpM=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96511,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa6yvBCRA9TVsSAnZWagAAdY0P/2soAXi0Go5M6WFSd7U9\njVrHzKm7hHjbRm1evLZjn0RuO+ZhlRXECdWd8UK1+E7T16h47JwsY4tb+bh2\nY7g8Km4AiRZ7dK9SinwoKUHi+/lWbK6dhC/e4EjoGapkWli+t9C/6boApZIT\nMtxHdR7s0xxHiXVCBGea0YIOCSCD8nRjCTsGf5SFTVEho/z8otmV7LmMBPVk\nxiyqSx4WAGFzEOQ5fPNPnj3/fi9FFWcINAcOjHEcm+JMc/2tEAriZTm0ase8\nck633Ns4Yr6d86EojmGAfb5+2nRiUeJDSuVHC/G2gvx0kIbGjj593JmgEkgC\n2xjbNvjv3TYtW3ObH3G4JHTKQyy5ZqrNBwP/BcBaBI7ZHEpzTqBrTujxUPYs\nX8ZhIQS5ZGYqObBNrqxLwG5pKR9b2FPdwfcfBOQiZGTdBLnDEVQZsgTT0bvr\nVv5SKsEQ4IUGcNeNG+XRm0ecoRSjADLmRfCZMJsdFAtiQpKmVUPV5v5JBK+4\ntdiKnoEcFD8+pjmvSlklm4pnLwBtvrD12hnU+eHOa5WNouv+XkE4BJNs1eGG\npQXknpW//yvEbxMyHFyCohZ7ATL0K3JXAs3qpuRbsxtCPE8xrtvyb2BdLkkH\nMol7yNrUki3AB4E9QRx325+xqzRhv35YgZxf1271RJUs3owhEAlaXa6JYRdR\nrX1u\r\n=yy0l\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"94137e65c28e443f49cfeee6be1708ba3c41aef5","gitHead":"a43d0922c0cb0158caf33e367aeee1155b25cc6a","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.24-PRERELEASE-envs-206.0_1525361601275_0.7108516127406272","host":"s3://npm-registry-packages"}},"4.6.25-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.25-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.25-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"bfa14a4e8eb195f49cf3c04e37aacbe09d4e67ba","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.25-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-OANwYTgcULa93TdVfv1Q9HjIWHvgTOeT90NxZoeKD2SgLmx2hA2FgqETBAW1OcAjr/Z3gPJBVqysPF4faGcumg==","signatures":[{"sig":"MEUCIQDG5/kNlKpsn/raqOyfAneQPvutLhAv+NQnebKTq+DAtgIgJl8FRDyw/WGsAQpZPGPnlGPY57rI2pl74XF1uBfpHG4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96799,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa6zeoCRA9TVsSAnZWagAAh1IP/RzjE+l87bXIL+AQvDc/\nAda/c9ErvogtRlZVVhC8f4Ui2wj1Y+U9qnFsVUeXWX6UNO6FVmwcYnm/wI3q\nulMS2iBztjggGbslHErQ3FpZnkL6UjmJ+SKPHVV8qo27d/a6Oqmfj4qQiRLt\n7tE2+46tYjPvMV0C2m7Xv7/nIgvS3Er1wPX8xy9PmWYBT9rRoOgDnzX7SJwc\nde23HKFiuKcF4TTiWvDvA5JANaHjNGuABPl60a62sxLKuFieassjctd+zzZO\nsUKZ1AaT9HmjSzIg4gkolrg620P+7WZpIY0+Dx8M/6YY54Oa1yBbKNjkF/7J\nxCO4v0zfL8923kqvD06LqeIbilvZ1+cEcl5Y2xCeHv5jnvggffHgZgRqLnEQ\nPguQkQP4ZxeVoFXoVDM18y5xo0GQ+CcG4QR5NDkqz3MJr89b/Z/n1TRVxcDj\nUBHCfvvZV7q9N3As8r8xmSkMVxKO30xCzrnjcP7K/6P6B6lkLbSfJotQIejr\n8Nzmf9n5MLo6ZcGvdWYeY3SakcpB431rvFzMqpjAKFavoLRK73Lpm5fVCemS\n1zu4zdmnKdlXPxPSVkM8+d/47fd7Oy0km/nWC+SIuDw6vvHDJwf8HUg7c94w\nasVGB+cCK3ExR1+YgBlbs88GRRBsTmej0Xe9cXKX38pyAB6zB7cUys5vvaaw\ntLdy\r\n=v1U1\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"bfa14a4e8eb195f49cf3c04e37aacbe09d4e67ba","gitHead":"a979f556eeae6d14fbf6f6dee07e80cbbef75bd7","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.25-PRERELEASE-envs-206.0_1525364647737_0.7693867516793318","host":"s3://npm-registry-packages"}},"4.6.26-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.26-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.26-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"92fcd9b5c273e5a26255209de0d5ffb7927a9b54","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.26-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-yB0LbC37/xc/9QUF5Q5pk4Xntqgr/aSVMN7S9pZbeX8vNL7kWu8Xe8rmHLmpkl9pE3TUYugSoG4RKUE2XgfWWw==","signatures":[{"sig":"MEQCIEiGfKSOulUnwcjNI5MgXF9P7hOl37Y1XRO2CQ7CLBEgAiAYMrsVnHfB0zhzgzeBijrJTrfchs+pY5x7CskW7gB7ag==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96787,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa8BBTCRA9TVsSAnZWagAAPC0P/2LBsLChabUAXfZetB8T\nOBKLCDf3+ywuXfg9CfhTlWZOX7R6nhQg/ES3w3ovTzdlFCd01bLKNwBINyOt\nFdoApU2PHBUfb4/ZqcfUCnnvpQDyaBldjXAEAKm39MtB2pRNB+Ud8HHmV3VG\nbm4xq7+DogJfW/nWyWETKc+08xUu0tuXhF5sryjih932/qsYKRoGEwj/VzzV\nkm3Nz6LfKGm0KrhETeDfic317wLKfPE90i8XjEnS694O6q8ZUCKkaXOs3yRT\nMIiEMC43PffO9QsLyhvjJ22ImBgs/tsADjJh1kUO071diALxlgX5pJvahltK\n9haKp5ZY2LVZHN5KuSpT1snW/GEoM3IXnJT1rlHB249eyHCjxpkaRotXTQ1W\nF23o/JdbA3JjcudXjq9XoZ0ZX+hmEZ73f05oDtkVEg54GcWUVinZRTOU4W3z\nCa2geGvly0lSSwclgHE/NKWUkIkyJ0Idoj7VuQj7KkZOzu7kS4bSz8p/K2mZ\nRtpxRn6Zmb2hi9bcjpJkFw1wbzlebrNvg2OUKSRH8bUcByaz6YI7MzzmshyQ\nO7jEoKJA1oURcLyOW9+Iqc4YoM7G1+/ua8ehz7946nABtijA9IHGAzXS9AJJ\nEP8hncBwpjmIGf2w++1YrC+kvfNHogqQYCgxvsWDOJwDEMkwVhZ9ijKXHSy8\n30H7\r\n=AW61\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"92fcd9b5c273e5a26255209de0d5ffb7927a9b54","gitHead":"66f5c8a803e57a5dd62faae63c9e8cbdf1b5d1e0","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.26-PRERELEASE-envs-206.0_1525682258233_0.30754247731929096","host":"s3://npm-registry-packages"}},"4.6.27-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.27-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.27-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"29e99853722b5c4c2cfdab63f6a633ea3c961422","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.27-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-zqssV8s9hGxy0+jyMGatFpJTqHL9r2xdtIVmsNDI7Bmr8DXwDlUdm5Iesv9VS0R+WkGJuO7HC6RQIXdNUxp+ng==","signatures":[{"sig":"MEYCIQDOIwsIT4gw/WaS6H6ET//dulM6PqBEAfRt5o/OA5X6TQIhAPWxlQecnr9DqLdSqejKbU0RZjlmyC/Q/QuDdrEmMvVG","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96896,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa8BWfCRA9TVsSAnZWagAAvKsQAJv3Jg4af4QvAgxX0Tvp\nwiUH6SN86bCDsRWTrwo+JPoIW5I+yQodnjYDBd+j6RrA1WJ3AvxXtpUsvDnv\n7ambIE5gCBwZm1iJirT0lNG9lJ6r0PXd6GOEm8Igflp6KOc5MmBQ9vymk2bN\neTF6fqGNT2sW18P68LcFaxQfkisOzNY0ToAI2tHwtF4vK2x2ReWqSROAHqRJ\nPZUdfqxb3PYDZ4YXwi80lFct1JplUL3NO2hQnlmefi1A+aS3zfoLJB1d2CcK\nHWPklQDG1QXUIJu+DfXHqz/CcOfciZKsivXbSDBqPaHM+ZsvOlrGuPsrAPH2\n9oWPXwf1P9fskq55/WUTN8pIMK4R3LY9rvzpf7yo490aKl1FIUJZql6kZbuK\n8fQF3et+7xm9Sckf20KH+ag3WUW8xYnE6WcqrryRUTurCTK3L1HMJihyxRJh\n940dMO5dNNUGcBQP+x2SrLTHgLvWi9yNFSo9/em/IZ6o2sLNyZdjjDveNYeN\neMJZEolOtN7ZQ6eRV37yJNyB4ZqvLJbPu9HdeXpZdYofXL159qkpyqvj2zmY\n6Sl3TyVOtfL2CAV1mNyw+zMlw6d9b4ItGA6HaLC2VFZmAG55uGWFDrIjFAgb\nLA6dSv85k3zOPl9WQ2JLCQ/WukDgY0WNoTisAdS6PKdxHZ5YZkLi9IsXn44G\nHnhk\r\n=FNhf\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"29e99853722b5c4c2cfdab63f6a633ea3c961422","gitHead":"92a790c40f1a7d15143c52952880abd5cc300007","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.27-PRERELEASE-envs-206.0_1525683614388_0.08508139307300255","host":"s3://npm-registry-packages"}},"4.6.28-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.28-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.28-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7bf105dc3656be99be103e196500c8676c9b73e0","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.28-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-uNUpyZ3WEvKuw4eyjU3cAQYNdcQ1WwuYenAJZ50g+qA7g92OTptrsvhXfreUEtYu85YmwnKbyuWfQD9anDEX9g==","signatures":[{"sig":"MEUCIQCozQ6G3l0QyVcG8MlxFSwI1b3gPf8nQbgnKNPATHtVHAIgDDSnu6fRbpniEVYRX9L4DFsv4Zx+esH1ere0SdinZMQ=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96897,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa8Br/CRA9TVsSAnZWagAADYIP/0RQfwd/KOpXSIL6KFuF\n6QTZkzPH6QghNFuaUbgMvF1Rh3nvUkztAhVwTRdDPplZ/U7/yySmbM6Cd37b\nLeYYxJ5XxgnDruYsBUw8la/9jzHa/x1pjb+sdWxajagmOzq8VW+3uJxCFaLt\nFTk/PLc62esaQ9ZF6KwWkwtdZQvaqQPjmxmKRX6LM6yVyZHb6zSnbkabopPp\nzrwCPyNWgqU6u6HqcusaU+vXdoB5LPd1f40X4nSEK7I01o9q/8GEnm/76A3m\ne38XfAuHoOYEo0YMPnd7+9N2zw67qarf9k4XvwZ9RTS57ezcbaq4TAUcNZDD\n6K1LLNLPGFsyii2R7OCzCZC2f4g1v4wytA9tBrmdz9pdI8506y3Tt4wFRMmV\n3P7EE3KZa5BTwdIK1/ruTBQFF0gfBLB0WtYfPehUnRtrL8y8TGAF9pQKOYC9\nhzrZYuZy1O0a84dT0jGuHEgZaAgVxXeP2qm5vkWaIzO1E9XIXxL8m6aSwIVP\nEc2rdp03LCO63LdPOIPZ+1unCI4ZYFPp0urfl+Ru3sIYmjA9CNwJ/LhhKWKR\nhwuffUHB6oZyCqwBtcA3Ctg8TYyNAVa2yPcaD/eqXjIb7A/CicWfSYl9lzYo\nwX37YQeC2cSP9tkkq0SlSiwUwglvebZFY0ujpZvZ65+Rm49NcoRFOSiCwHrJ\nPDs2\r\n=4hNx\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"7bf105dc3656be99be103e196500c8676c9b73e0","gitHead":"8e946cc653965ede2fdfe9de1b5a1f14c40684df","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.28-PRERELEASE-envs-206.0_1525684990300_0.48350868655546164","host":"s3://npm-registry-packages"}},"4.6.29-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.29-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.29-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"ac14b549a7deab906e6fb8adb8dec3d522d28997","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.29-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-8ICC/nwz/z4vC/RLMLymiH1IIBRO/ECmFIZO/nd62gy6pxXb+CZLzjK458QBLXgAdTCxN2dnjhi+Lljfu9JsHg==","signatures":[{"sig":"MEUCIQDHr89C/Hwnq3ZlPmssSLcXETJp3JN1iK1nhZAf82IsIQIgfm5U8H73CuorsoERKYWM/zNDxPLijcZmHw99IRcZYV8=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96859,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa8CODCRA9TVsSAnZWagAAtDAP/3sR2TJfGv0UDCk0zbx+\n7aHDOEyh6FT5tsSkVdgcrOy4wWqL9VquAZURortTNmSBv6Y97t2HG3+owuSm\n9A2ZlV+W0CBkB5lBKErMTVbynTjGiAodLnIQwVQJGsK8jkZIwYPGqk42B4qW\nkOLXYop91+MPkbB8T5wc6LeOqUmGEa9EJ1lOl5cL8feo3P7OzOvspIS8QELi\njTFYM9MIWNFE9/B/fLOZ8EJP+cOygpULMTC0t1k6/fzCUJWi8O5LtLx3MivB\nxkTw5LhwUjoOFR47trM4m6cfsI++fZotlPPXHvEAPczcKOzaAuevIroGUqPC\nT3uzrb4hjLE4E3GDk9umVShekNcQTvAGkYSDVVV87HTxdFb/io5LifYtibwt\n92K+3vQkUE6td1anH7S+UNYujNasNpdmIvA11QvhzIMyWJGUPtoYNJmnKdxt\n/4H3jtNPkXQUZMwkSiZt6NWWXyHW+/FFV/Ym0tCHaM9LbHPEKzLGnrAZPD+/\nnvlYpzpW5WdPBwXGhDfDKBne3k7v2kTuhy27hVLbJOEUInYoeotv6BEkK6na\n0wugYKUdAQ35AStsKESMJQb+psCa5kXCGyh47AvCD5Ls8dYfwSNJkQqOTIZf\n3LEyKaTex0CNRinAqT8jYvDKYqD89iF/Z3KrxrQxFjRszPdtAukD0sXLLKef\nKNLY\r\n=p0l2\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"ac14b549a7deab906e6fb8adb8dec3d522d28997","gitHead":"dc07dbc7498ae2d3974a022c3b3c6b4e34dfaa8d","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.29-PRERELEASE-envs-206.0_1525687170567_0.3534948774161315","host":"s3://npm-registry-packages"}},"4.6.30-PRERELEASE-envs-206.0":{"name":"kit-deploymentizer","version":"4.6.30-PRERELEASE-envs-206.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.30-PRERELEASE-envs-206.0","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"d48501a9f5ae5814deb96d760332f9d28048ff89","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.30-PRERELEASE-envs-206.0.tgz","fileCount":17,"integrity":"sha512-PRuPBK5d7aGM2xOHoVS8Lx+rbZnkR+jILYF1Q/1sEcRMVI4ZL9zTKMHfZignZnfiSvh1NCKzsDFlzDWH7JRyoQ==","signatures":[{"sig":"MEQCIB39HYk9DieJOp31YSSe94NDRiQNANbd5RYedypsXUkaAiB6VW8EPLGBhF+HjtcfwIZgLNASEjnq3XF9TAUvb7rUPA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96870,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa8dFtCRA9TVsSAnZWagAAbw8P/0zRPi9hNrbhXwzGVW7X\n7X4nVQyMIpfXKFq2IaxOPISnTDVOU1db9ec7QM/PjvMlL+X5u1CXmn22SlA+\noU7+fPw+EyqOyBcgdCv5C5KOP1rR0wQWToO6ui+3VphvQgu8ZF6vYzi0I97d\nSxEcnWPCx2MBoH4H6xLbmRfd9PObLcdkXSE0MNA9yicqFECx5KblMbvAyGXg\nSMLiEBvko/jhxq2d3QjdKE8nmt6kcmBzqS3f/AXFQv99e/XRgC89O1CzZEbN\nm9/xI+uejdKskTg1CaeKkV8M4GLpIviDYf/Po/YUsT36ULb49xWu4zPzj2hf\nC237Dx2XW0ljJxFuYYkppQBVkEh+xpwddDgJ6FFC2V+RtRxO/uilm/VOcNky\nwh/6nYo3oUAIp9piqwy/lwC7m+bLN0MnMs8Ncn+GvTANsrEDAG6TfBj0dxkQ\nVlUJ4NuetwfmViDFMJbmJe77nKQI/AVldEvB/DBnt+zC68BhhWApRZe/sN6i\nZepJWe8jZ6TZtfeye69GwtgJGXZ0pBgy0PTFLIF2yM312QT8h56avFUMhDwK\nH0ZE1WkZNRFdQNqjqRmFW9NT7jeDFVeRGRSx7OThf3bjj486X+OWyGwvniIT\nDe4C48/SnXu2V8Bq1cvEifIpanqh+qKJF20gNdu4kGEwhK29j/xQiDKfnzsy\neRwg\r\n=wiax\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"d48501a9f5ae5814deb96d760332f9d28048ff89","gitHead":"6f972a727e6ad5f0a4abb0ee6aebd9415a1c14a9","release":{"fallbackTags":{"PRERELEASE-envs-206":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-envs-206"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.30-PRERELEASE-envs-206.0_1525797229087_0.11912601859431615","host":"s3://npm-registry-packages"}},"4.6.20":{"name":"kit-deploymentizer","version":"4.6.20","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.20","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"ccf8e96d9ad86b7c9e599ae1972014e27593b5f8","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.20.tgz","fileCount":17,"integrity":"sha512-Kd1DZmLVOTfHMo1pjkPgaDQSBWm9RyDJttP7vpuHJUhbLkOQ1Q5z6KDcGBLj2uxc2JBafOpj/qCRd8v/5b7qyw==","signatures":[{"sig":"MEYCIQDqtFSJN6z6Ab0ol31Sf17OfB7xz73Qm/RoPCVRC+Cy6gIhAJpq5A7nlbcsrk198lsQhhQ8/7dy6rTzz1lBHH6D6+n2","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96703,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa8dIWCRA9TVsSAnZWagAAO5oP/j7eUJq2BlsG0h0qo+Z9\n1TUScan6HQiHpW64yXnbbjHg5Hspa/BBrleX+MIXhWT6YMMrqs10gLrXcsGV\nXn8fttwYC5MRd/XGjknucLSub2epyNf5hUp/fC6NSF2rl8QnU/kECwQXEDZA\nHsQMon/Q0T3w4+8BDVK6czYiObo7xEiugPJ5kMZZNDy2Bez7QVGyw55RMxoo\nu7mVRsjheJCwbQa4adK2ArFWNQrJUhKCFt0G2xNvjAlucxjgc70lW0KwQe7r\nVvjVaKuT/leoI2SuSCzIvJ7RxlTiZt0LG6tPWsw54QPPR9Fd1j4QMzevVShY\nJO+HR20hHYTcxX+qMW0ofZdyYAFjuyGwD7N3HCffCKQNtNJFoOyveyLqo8HK\nY4UFMLVrOhVyKuCDK1W2OimOKmzNHSi5gfBr1c/Pl+XhccNXfCL3knhHZP1X\nMZhMIxFeS2Z920KenFajhgpkUGsv1tKZ1JX58bP8ec2NPINbZGHZrslG7Hs0\no4DmhzhUGatIKLhjf50b8wywhvj/lqLkTZjJDnMqJH7Ry8EBs9MmlVL2M3OX\nYjOoXvAE9PhzqOHfFg5WPhnSsH9OA7s+uKKgCh5eym0rxXJWxD91F9DdvTz2\nXfwndXfhjt+VTqUuG41qDB9cNxhuqwmPOMps7krSycC7KoTRE21ypMmcQo/l\nrGja\r\n=KU1M\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"ccf8e96d9ad86b7c9e599ae1972014e27593b5f8","gitHead":"e37eb3495da1df611f3e4de15ce7ef55dc79f71f","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.20_1525797396473_0.295368445373553","host":"s3://npm-registry-packages"}},"4.6.21":{"name":"kit-deploymentizer","version":"4.6.21","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.21","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"f468ae686452f446051569f1f5cd5f2901f1097e","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.21.tgz","fileCount":17,"integrity":"sha512-7jtj2/OC1NJefS9qo1eKvP6dMkrGA4CQiFFm9HnQqtDeyfsNuIO6ZTJiYw5+ln1Ju0Hap9RX1KGbKITWvr3rog==","signatures":[{"sig":"MEYCIQCmzFTwVVDPeMWxXzimTdHyIxs4SvyenkQAnfLXcCXUyAIhAIU+oWWQOAo8jSFa+OpzHQgaL78ZfW/b8771zUeQZN9x","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96867,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbH+tVCRA9TVsSAnZWagAA76IP/04eBdx09fsIk9gq1N2e\nDfy/00oCdhXoZ5/lQI4WPUoiUuR/xzjGTrwQ5w96BB72eqEAP988O3jTr0Kq\n626PwizFi1WmTGROZT+PABjGtNDnU7tmpgJ/yreAsvwdhBhtKtw16myGtNLg\nsHi8X+sxFXJ6Kbf63ymFbAtrVU0eLeHRyx8IUYC7YhFZsm7povlQqYbfqhvO\nRZzGhN3DgrOUTTeiMETNuitcmpQil0YZ/ipMlAuNmbX6tHdYZvUnpNYyN1Mt\nyQzQ5wfnSrhHYXqgmDqWTKHmq/OO1L+zCu+ldyaKi7CRLiPUMtfj5Cp58phX\nIHP9tY24ELrgjrHOplshwdGX12YpIw6VOiv+SNFlXzONOBVNtSqsmJ4IlhBp\n0e+l3KK+wt9N7hOFGS2z9iW92pm/KRpCrvtvIFKtaDAA2jG6qUnDyF0soqq+\nfnQCFIiLFVpgR37W8thjNqTvc1SmbYdPZRJhoRQ7j5icZ9oNnCHzo0/mevnZ\nIfCAkqqYIkuLl/O8RyoML+1teV3+LO1UyCYreyTzo1p6ZSyQGiqyDgss+NGz\nKnsyvqf/yjjy4QdYyvwDBHjhyaX6PTbN5OHQTcCBiBM5X9Mx1wXgNshlacCa\njyq9dz9vtcMp1VFBHr5mimyvGDwMwQp52+N9KY/+igspDfm0XVv7PkPr5iZf\n0Uqd\r\n=sZLH\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"f468ae686452f446051569f1f5cd5f2901f1097e","gitHead":"a4fcfeb0e37579094eefddd62e52fa71c098fc3a","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.21_1528818515175_0.18848641481957773","host":"s3://npm-registry-packages"}},"4.6.22":{"name":"kit-deploymentizer","version":"4.6.22","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.22","maintainers":[{"name":"chesleybrown","email":"me@chesleybrown.ca"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7051d769344412507cffb5a09267c15efe14b87a","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.22.tgz","fileCount":17,"integrity":"sha512-Wv+rbq0OOwOhPCLUC3+5TZMghu7f6qtkoWHtgvWZcl+2l8jtmzq1cHu6Wnqe1Wet4v9jBpART/eUwf6IEzWOSQ==","signatures":[{"sig":"MEUCIQD/ES+rfrq+30RgyLuULqa/Da2JhH9FW3t28qLxmw4H3gIga/ip3xQteafTGQABQFCQrcwDe278VJeULkzcmVShuPQ=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96931},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"7051d769344412507cffb5a09267c15efe14b87a","gitHead":"8a5b2a7340fcaa768ebe853a7563fdd0eddac705","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"chesleybrown","email":"me@chesleybrown.ca"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.22_1528829435367_0.5122808210505427","host":"s3://npm-registry-packages"}},"4.6.23":{"name":"kit-deploymentizer","version":"4.6.23","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.23","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"eb7b78e60cc4f2886ed4699c18af311dd46ac6c8","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.23.tgz","fileCount":17,"integrity":"sha512-BgY/Tr9rJvEXBk7NEWJ5lqJMCUENfJcO5iYOA/PT800mDjxFC5XnZRROcX+085WgfAJJf8NktylrH8U0ZzwM1w==","signatures":[{"sig":"MEQCIATICyjNNvblGcOasgjcf5qNnb6jxAKci9SSmYV0TPreAiA3WLQggnS4kelmwAzMV3YT4Vdf1P30IiXhU20saPCs6w==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":96931,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbajyGCRA9TVsSAnZWagAA7XIP/AvIcWByK7qiNLAIDXVB\n4O/i/ZFRk2SKxU6eUEQmMmukF+ZRm58zpf3lYjOYoaJHhJgTUmG0d82YcWSU\nszhnnJSnrRLG6C4kgs6e2mynrFnJPlEtBaFFEy5/9NWVfDFeQ7F4tv+Hv2x8\nv1TJPIKikQVn4olZEQVZ9+nf7+MBTBBOMDjlx7vHm9rcvxsm5J8dYwZ7OeKr\nfOeWgxwCmKsDsKbNd8NaKF4Da1d7ThSAROJL1ukcNxIClW3IYGVnU1PFNaDu\n2j0KJ8W3Q1A33hjuu/RiiV0sEwjyWDjdO0njIVLkEwuFvGA3fi+/l2YfxBRI\nZKRNE0XACeFHrWEeLrTeWiP/uzjYaqKGZscDi4KXXxqYpbTDGjr1shNn8Hsm\nOcKp4ZQnpR6XozBPRbo23roJC4oh2ACfS9iJx6pCJPrcMzmRBsEtlRLJ9rrf\nsxqdt595rhJDtp4p5wI1rfV+kwHnPoAfUuDZyayzwdcqqZoJSSqLIUlCPVNK\nT7+N+GZB7GahHeWvTbp+o9om3rWFZe4CLMv1YnplDCGRJ4+dGyjao0YyH9R7\n35qpigky+c1p/lPWFGneiJS7lZADMUnQDsfKifrk5QsncmAtwDMi0+AOBoYF\nBmwgZk84+PckTS5AY9xaAq2EiOI54Dynx7CcXTnrP0UN0SXPDadwTbwBkidu\nZqvT\r\n=fQaQ\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"eb7b78e60cc4f2886ed4699c18af311dd46ac6c8","gitHead":"6475aee9bfd1d9d7c73602e0009af4e367e7a124","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.23_1533688966737_0.0210445297934867","host":"s3://npm-registry-packages"}},"4.6.24":{"name":"kit-deploymentizer","version":"4.6.24","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.24","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"447ac7907f68352d62a0d1e3280d895c769126bd","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.24.tgz","fileCount":16,"integrity":"sha512-3nrM0dXmdQt3Di2mcRPblFGaMKaaFokPU14A3gMAHSofSYO0OcuxIaveDpM2vRL+F3rW+3Pu/zRt6zelSMa3cA==","signatures":[{"sig":"MEYCIQCd+MgYjRfxT2nLBC+cc9mWF9Dg/nn9HgXEhsP3lCwlCQIhAMbQW9CSxrS6kT2vIfP1oCdWEYpEiTgxpBBg1xbLLOu2","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91891,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbcV9yCRA9TVsSAnZWagAAikUP+wYY+YVtpHvcXtm53Ht4\nyXeX1TTHIcmUYcc7rxMJr/0tuQKywA743uq2RhdKc1cJ8+ELOrIcKsXqFyD1\nbqG95swt7GdYgB2P+Db8OlWBeXH8rb7sBIsKKKvOPCAUSAln4rJ3G59wxHjM\nLh2GmYawhTQ8Wpp5/iFKxw7qmmSZ+9iOT4N2RjJDlF6dOD4Ey97SUluQyABm\n0wwwIfyZo1ADE35hUDZ/28WAXFdtpWbxJ6NTSRMBdyABdfC6xI5rt0zVx2P/\nqko4UxtuN/fLVkkna+qHy6gE/SBqxHO0Dwi0DvYXP0ZAcBzJKH9xmVNOXmxd\nGDAipu0/r/TieCS+Zq/XUF9PQdKefDpsWLkgzILWOnpcY1JZDL00CPx1xXlw\nEZfLkzC2QYMMcaTLPWzOkOYMZFy96qkFR1pd+CEN8HUGDXEzsTg8p5WrqufO\nuc7DsgddtHiFmkJzmDVT2+6opOLKbJlEMVsboIKxDU/OD1+bCSaaDA7KYiOS\nPpUuIN4NIWUlXJCbO5H2ekDJT0OSVpkF0P2ksEfEyq65fm/sByKUypt5vVrg\nyhKjzYcOMtvJjfKQi91JMH0BkmhWel9riup5s65A/CRffXMJGBb71r1g5kc8\nCEKvncBhJNdj/oalTQk22Lvd2mGcFMN1JImJqb6cMpTUOfq2Dwr4wLKxAmRK\nfj4X\r\n=mgNI\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"447ac7907f68352d62a0d1e3280d895c769126bd","gitHead":"20c872c9d389af4aba56169ad58f5283ff84c817","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.24_1534156658102_0.9438665392266266","host":"s3://npm-registry-packages"}},"4.6.25":{"name":"kit-deploymentizer","version":"4.6.25","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.25","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"a3bbeaddda5bc5e8771222122ae1213b3f28c960","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.25.tgz","fileCount":16,"integrity":"sha512-g+KXcJh/mb3AGU5dHOHfoT77WpDa/HX1ltTSQr7tnq2Y0Hs+PEeL8dEtw/D7XZmhkk3ILcnp37Om5dHCLrikNA==","signatures":[{"sig":"MEUCIQCwe2q7dwoSAk2LRjYZDmc22oaK9L55pkqUFUg3BNxGkgIgfmckhNabbLFxJNHyxme5ANELwti+MConjr49njX2TTU=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":89228,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbdFiOCRA9TVsSAnZWagAAQ9UP/jaxMid/txH4wfifWAM1\n/SXYCzOXeF3lMfmc2FrpeNt37hBLFrxONj5DYjIBMCuCcvmXjmyn7nOQY2yF\nezjL+E1L8hnD6Yh9U1mVhwyBlHcxNu89pOlVscQnedTIKBp7/N1ieOAh+oEZ\ntI/eOrtMyFr5M6yni7XBvjDIt7/B7lltH3lJ1MRr88K9oNcu3EEF0SY2Nspf\n9YuHa7uM6CIYGqHZRXLDGxwwUA7e6BE6PdANasnYm0Lpf1/w/aFq4TXTDryN\nwZj+9NP63/jDAVFpyardaz4jEngl6lyo8f4dMsjok8P6aLOnQ4Z9aKqe352e\nyRODWyMDakULvqt1sroYT6Sfm9954luvIfBKrR4MSmLEN3URf50THNTighsr\nAjB3aFACqESucyxeseC87SEtTpSaNT0A5ygeqjB7NxQv8YwWJGv6XgduMQXU\naRw4tYeLR6zvg1+Jxve/rkacNVSkB/7IwIqMf/q8bn13V/CdMd8AqxR/YA4e\nYq1Et/LmgrGr3SCPRsLUuHniiYzguXkr7H30nnecAk9JsKN3Dw0VLaz5WeUt\neRDL7kbcbqGX4O9wHMYjueRt9dVjchvz7ECCA/EmBL21PRRCkg5XgiW5E+68\nKjcawC8Eu3LgPb/YLTb+R9Dz6gAv5mj97mlqawGXtjLiozOo7jmugpC0R5Qc\nCQ17\r\n=VqYw\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"a3bbeaddda5bc5e8771222122ae1213b3f28c960","gitHead":"fc4b8fd7d15d4618cf0138c0cad62de991846001","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.25_1534351502525_0.4094789782211756","host":"s3://npm-registry-packages"}},"4.6.26":{"name":"kit-deploymentizer","version":"4.6.26","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.26","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"07d3c2ed01f666e1b9155f44976a5f94824daee2","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.26.tgz","fileCount":16,"integrity":"sha512-e0B57SbD0JdPLUoYEYvj/Q5y+NJMEq/6o8W0vLfFN/7Ul1xBVap0ZvaGKBLpQK5B6xPJZ4khRszKtveJdXTzcA==","signatures":[{"sig":"MEUCIDVsHBno76bYT3OTOZmESpmjsFH3WcjIVRrXxHvrXTPLAiEA+zae9DWyRI1VV5cd/kU9wVSgiR6wV6fiI0puePiIYX4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":90375,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbdZ8ECRA9TVsSAnZWagAAe4UP/0LpbFJZgvTMTAjXrx7R\nqLmIrfumXx87qVMNXDupXAKoEk1jCeBb7Y8y4rdVectCoXnX4xJO7fVX4Z/q\nAUUPas11vOKF2eb4MHtVy3wDjLZoZQ/sEP7m9yFcP7m+Myq2boCJBa+ZAagk\ny5mCeSIWkZTvXijIONS/ovwC53JroZBUGE8nn4ssgTsxkJByAyG8MrAOVp5l\nKsYv8I4vlhi53YmwQzNlVV/ln18kD0MgCQB+k2u+AAGFf1kYpKf+jdNqJlhg\ncHSh6vBC+M5LTMkoPbZzZZuN/53hOGpNKI19wVS1N556l2YzUiqMdRcaa2qJ\n0JQtYSxjouemgQhSnG72RyleVfVFz6fV6hpa7lX41MEkn6Tt3ZUBrYPXYRBD\nsaIqz6fQbSHyw28lHv9ofZa2ENgKUbfCxRKCb+bQJTyaaNMMTEk+5iaBdFfo\nxkvAQw2AhhjRayax48Yip8jC4TGz4jF3WI4VfDvLDe6uV6ykVt9Y0ze/kDdi\nI5eqafZpDl3qe7QWlfUv4BbtZ9b/M14a+e2MJ4l+zh+HqqZGg4onffixG9pm\nK5AxCd2vNcbtwum3jCqpzt38YmiECz/nHDJ/dlvtkQjfKmZY49unGYeIp5WR\ncOITRpQkcsmx8FA7vTRLeGT3vJweBL50IcifQl+3sSDDqK3KcqTUGFpuRTIc\nPBoB\r\n=P6j6\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","files":["LICENSE","src"],"_shasum":"07d3c2ed01f666e1b9155f44976a5f94824daee2","gitHead":"c7d29cf584947426855884baa049778c5d859688","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.26_1534435075800_0.15250594878210344","host":"s3://npm-registry-packages"}},"4.6.28-PRERELEASE-EV-1421-promise-bugfix.0":{"name":"kit-deploymentizer","version":"4.6.28-PRERELEASE-EV-1421-promise-bugfix.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.28-PRERELEASE-EV-1421-promise-bugfix.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"78c01421eff0a9f528c5b337e2f5f225c1a449ca","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.28-PRERELEASE-EV-1421-promise-bugfix.0.tgz","fileCount":16,"integrity":"sha512-0xIttqCE3GOFz2FzQcZkywxebzKFo7YupTTQPDzdRtueeSlzc3DY3EKSYPO0+ptmvo+o+C8iK2/7e6YBSvAewA==","signatures":[{"sig":"MEQCIDmuOXPoCp1OPLTb20ZNjpmEoP5HMWFBbLpVsa91XY4CAiAyaO8pSr9H7z88zYj/H3+j3ouZ+JUgT6Nh9mlOY4ADfQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91063,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbmtNQCRA9TVsSAnZWagAAwLUP/2jij2d2mJEjKaj7Shd2\nG3uKcdqxjji+nuQDwoZZaDErCwdsbOou5aEcdKralxp7ymgCcvmw+r8bqf20\n63ektI6JTHeaed3ketBx9A1bNub04kQJLkK+8jQIyrBRtQer14/wniL6adQD\nnwtD0TW9ifd/TApMcEVf4coPXd+BF+ZwywAD4aS5/rIomlusBxmZu2Ss/yPd\nMZe/Zy54c8fMULRZqU2brR8kWr8gBStTr+Uia5bzlNY6SPMNlPaG6eO6sfea\nzxRgEJ4g6xTaxlZQ6OWdv9IiUxE9+BaA04lFYoXIzkzsm3bmOzkp5/cV3pFn\nwqRWroE0NNqb/wmwgYMKot8tX8n/fUAfm7oJpthJhoanJE1SO+1MLxsDA8EF\nEm61o1pCom1USJ+/OlmbTu0ccRFjEU7X0efIUI+G52BAPQlXzoqUpWHqSc8c\nWsLJGwdvRKCJm1b60TVM9NbM2vtp6aAy/GLI08z6YB1S9KK902VmnikunJpw\nuB4UKKVNLOQfODegc/0q8qleAgvpJ4MR1uTpoLG0ooWL4kbpff0CNo5DP1ws\nGAI173K4c1wPs2yEcS7h9XcxHB97wmDwn3wLwRE1YXH5IcApTLRHTRMZm4xo\nps3iCyiT0WIP/4F38rN/fLSNjbWKQwodeeO1N0hy4hP9iq98IL1M7Nf/GAsE\nGz8F\r\n=oOwX\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"78c01421eff0a9f528c5b337e2f5f225c1a449ca","gitHead":"07d96169780ffaa97ab870c4fb4fb0b714d2718f","release":{"fallbackTags":{"PRERELEASE-EV-1421-promise-bugfix":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-EV-1421-promise-bugfix"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.28-PRERELEASE-EV-1421-promise-bugfix.0_1536873296119_0.3149052905469014","host":"s3://npm-registry-packages"}},"4.6.29-PRERELEASE-EV-1421-promise-bugfix.0":{"name":"kit-deploymentizer","version":"4.6.29-PRERELEASE-EV-1421-promise-bugfix.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.29-PRERELEASE-EV-1421-promise-bugfix.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"5c601910744eb265b3e461973011042ec38ef9a0","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.29-PRERELEASE-EV-1421-promise-bugfix.0.tgz","fileCount":16,"integrity":"sha512-mElNX0giDLZfaktjTV/3J7EnutqI6Hf2cHZAUNwNS7k1r1MJ6HAG3ZD2XrqxTQna3roLlvnHg+ewrOgtP1kp/Q==","signatures":[{"sig":"MEQCIEowVEhz9k+oPO8urx+NP4TcSXQd/TsHL/mwxvyT+s49AiBNanKu/3m0soYKR+x+eUeMWcpxFN3q/zJHCuWD5OZxtw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91382,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbmtVdCRA9TVsSAnZWagAAi3YP/2T7cijbpqWlRnqnVO+h\nZqqZMS5Sp31jnVj06wYXGslkOAY1IpeUH5cdN7iUD3CTDpckeGElmy1cESCb\nIefmPDW9JDgMRmr+UiCNp42IhGDLYjKmPbqC645CEmQdOncbJhYnvVrg8M+2\noVkQ1xpeRx6hQ/qADg/nwyE08xq9MoXm9wWHSgfSGHudHl24CEtHTwAP/ves\ny61DasD84BOrYePM6w7aHua8Eqeja8CK9kr2Px3ZbGxWbvku0Sr602FNjGYL\ntphiEvcMc8ju95bzFK8gEBT79CGAuy5UOYbpBSN4AqtEPLuX7n3SFMO2Vitc\n5BItmVKDJsoE80qY6gBqniuGCDBujKH5TO6UjpUQevSjWw7VN4T5cZTnebeL\n0EqbUFNBbfDSJaUzoeo7H1HL7NnpZzvIq9HEDEKze4NGw2uFqbiiKzt6PvRN\nXjx4uthuu4RX8bdCIh3dVgW1KrN2h1jKQT0uPThCiiMhkNKnfnPOwCJSo6eP\nk1EEx/Y/BjAblg0DLd36NSul71U7KrIxcrELy/DiwEFaihrvx+AjLia7mMoP\nrNTZ5Xjw4om7pFBRQgeH5QQQx5FagHt/DabyOt+74kwR6daowYZORkN09sa5\nwlGsoqSoiFNROto7p2Mr9lUgxFlm0lft0wQ5EdbxtZ6BKWHa9+mMOEgGMUr1\nMAqS\r\n=B+DW\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"5c601910744eb265b3e461973011042ec38ef9a0","gitHead":"805b3872d6a1f471e991b22108cb6c68aef66e69","release":{"fallbackTags":{"PRERELEASE-EV-1421-promise-bugfix":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-EV-1421-promise-bugfix"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.29-PRERELEASE-EV-1421-promise-bugfix.0_1536873820477_0.16809984110603637","host":"s3://npm-registry-packages"}},"4.6.30-PRERELEASE-EV-1421-promise-bugfix.0":{"name":"kit-deploymentizer","version":"4.6.30-PRERELEASE-EV-1421-promise-bugfix.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.30-PRERELEASE-EV-1421-promise-bugfix.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"3366065f35a501a46d467315c71648b27b81d95d","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.30-PRERELEASE-EV-1421-promise-bugfix.0.tgz","fileCount":16,"integrity":"sha512-7gqLVmpPa3MBTZ6ay1ACZi0B/5ON60HfKFDD1Wi/GlxjBb/gRTXBntZp2UVs+XwG3SeUJweNAu/E31J1vtld1A==","signatures":[{"sig":"MEYCIQD77mAnhtVsjQVLLb6keLM556Div2/xWtDQ39uvB/JokwIhAKfZSJxIQJScNQtKfI3bBIKgMg8bXNLf4C+u1Jgxd1a4","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91082,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbmuCTCRA9TVsSAnZWagAAhNMP/3Q3uLsiEFSPlJJ2ZvQH\nIE6TU6Km5Xx+S9azkSX6PWiWGL4TlUO83ymfgAwpZ+IgsfOH43NhggD4yWq+\nv3YxpSDRfbLMALQ0EimwNNTQDxC9W2FEK/jzs/s8szatHS5HUt+6+eng5tCS\nMyZCf6Q3MojtX50IduVvlrXtPLfHdZN4M3mHxechPZfSXBtx72vMq0G1NS+e\nfWdutA1GjTeD/iqnGK7/YXqV8XybzvdgjhK+StRK4htZwWBD55SwLCgmX3jB\nHqn2k12OMMCnTJSbnbMmUeXKX6aiQ+Pwd42XRzW+kuxW7PHXGAvACbjsnmZ+\nQ9A+79iTjBYYC2hoKOvrazjLtYPLbTHVKtNUHGiB8sGAWQvm1sKTZOyQ0yZF\nruLcfoXroHkFbfK5nLXdRPoNUaRGTgclc9gnTCEadEI+qpY5zixssfaR45/F\nmb8NDMz645yb667VQVPfN+pA8KRlK/1MHbfp30hB9A0kLnpoMtZJ4kpkhGYW\ns2qeQFzg8Ibo+zVbb+B8r/gThWVgodyrbt4E35W1DN0ZRtqBlWm4kjOZHQqm\nxx7gxda7rD6hqtbIvAibnEkUoVbbxGNItPizmJxFjLTUyn8HT5veSTZklQW7\n/V9spiD0SkywtCBb50g+AMbFyIjtLcU2pGz7llwzk/hT+3jyAnqBcbRYkWOH\nduqd\r\n=/LRy\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"3366065f35a501a46d467315c71648b27b81d95d","gitHead":"f52acb2824d61e39accd4a5e646a79540c996e0f","release":{"fallbackTags":{"PRERELEASE-EV-1421-promise-bugfix":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-EV-1421-promise-bugfix"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.30-PRERELEASE-EV-1421-promise-bugfix.0_1536876690435_0.5109261675306505","host":"s3://npm-registry-packages"}},"4.6.31-PRERELEASE-EV-1421-promise-bugfix.0":{"name":"kit-deploymentizer","version":"4.6.31-PRERELEASE-EV-1421-promise-bugfix.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.31-PRERELEASE-EV-1421-promise-bugfix.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"6d76ee2013df31c2e5723f3879c91250df6460da","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.31-PRERELEASE-EV-1421-promise-bugfix.0.tgz","fileCount":16,"integrity":"sha512-1pmuJaG1qhr60Ytjy+XhGm07AJGclLsADuO1PU58uN+EwKxlBoLyML3BCEGCBLOEzp6Tg/dEnuw0aguXv6Zn3A==","signatures":[{"sig":"MEQCIDGnNNyFrXToCwGrwu2wQqoiff1Xzf1MYH1iTPUkAiuzAiAJKClnk78NxitxKUCnNbnA7gxvtHlPhtc4LOv86X+tSQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91019,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbmuYeCRA9TVsSAnZWagAATVUP/RjFigevSyp9u56p+HXl\nClSIFJf/eYafNy7qzL3vqrfb0PS7b6uFU6HYSF78a0hfNT3SaCA5jhA4/7BK\nPkWZ2HFSKZJByg3VJ3wI3ibgJRHCA92KrbSi9f2LNHQKdG22e7+76QSrxr3F\n/bmP9wuYWW+4SeI4M0su2aAziSzhrRHKR8Ip6VwFOU4iQ7xVqzP4qbAHHIi1\n6BHSuK0btpXKUSgV3AxrX+ihy/Ab+thM9+3cT1LOzIagV9AWEmaFxfNgFTxC\nlH4abo+y5TtUK6cJoqt6qCDprmSbq+s543uYaK+bJnDwROmOl837mVw3Xpm0\nuz6unngR4ksFsVzev/9AIF8bKFqFPPfe9Nvd0dzVcWmNQFAf92BeaaB9ju3g\nBrZaqQR6pwbuSh74CkysnDl5xD96qbui+bBjY9S0E9skRdbTDwKpSpb+GFlz\nwFPhx7amEitB8wci8jkUhfcQ8m6pCLMjkAa6nuEsrJLx3g3WNRhGrL9iMdxP\nDNecE63e85oL7xXkuyd6c2iRj2QFWQ5iMRtveIbmyvnOc8rQ9xh4X4KCDP6Y\neNSm14VIv0n+OrUIJymmxjsiN6zKRB1Hc+WXluy51T7tNA1vxP2qJ+kaElyF\nVahmSJTnKVQsC9IH/CskuSOUU+CMtDxT+QRQFDXyYTdRWk/3wjykBtiNUe7Y\ngS2W\r\n=tVO+\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"6d76ee2013df31c2e5723f3879c91250df6460da","gitHead":"c9c871d85abd61342bb47d115f8a4d2b3617c248","release":{"fallbackTags":{"PRERELEASE-EV-1421-promise-bugfix":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-EV-1421-promise-bugfix"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.31-PRERELEASE-EV-1421-promise-bugfix.0_1536878109637_0.6581099874414387","host":"s3://npm-registry-packages"}},"4.6.27":{"name":"kit-deploymentizer","version":"4.6.27","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.27","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"4ce4a87465e51e026080d09b1ff865c7f384aa4b","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.27.tgz","fileCount":16,"integrity":"sha512-JLB+x7KqB/2svPggN0kIJrauVs+jV0bN2NLKhUjqDcv9ygpYXbzYm3HqdrTqU9N74wHSKr/vUWj6zAl7rKS20g==","signatures":[{"sig":"MEYCIQC0RGb1/aeTMZ2UOAIWtCQmZN4j9/Ag8SnnsW9MQDu5JQIhAPvSjN7Ku7I34BX//gtMLx2ttRoPb2sjZXpCb9zSWMC2","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":90810,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbmuouCRA9TVsSAnZWagAA2d0P/3G0asJk14BNX3gHXk/T\nRvYNB/Hfl661EbnodVLJFgus18F8XKGJqVi2fh4UwUDiAZbRMYyYkiLobxyL\nvpZWw0zRUIex4RWfmIowITRW2Xq62Xq4t6E9Zarg60a99hQXG7EpJzJuJdoS\nxTvt6dr4Z8OdasOEhAgXghYSDXgEIgI7XGsSA5Eg2FP0PCQ7Ex0ODvhQYzQE\nZhZPPTV9EwKgT1d6agcf9Yttd+nJZXdJfElQVsRaUuRpYrRXJPxqrftKDoe+\ncJG87vK1zd0JQtOH+9T+ctnG3HX+yXD49ysc2YxsgOQO83SweeSWgfyH1q24\nOb20KkbkWJuTG0wCA3rATnk+N1a5Af6jErCDulVLsfZDUYPOQRHr7nKBjQh3\nuaYNw9VdoVjc3wb2DZdFR6lyzggNRq4sj1l/uXrOKcdtR5dIpoGs/niiJHlq\nCVSaOrWaan/7FZWMKPDvzhAPp9wAcmJkXEbMuAqCA7nYw2MQzrlG2zhxD7cv\nxel/FwjdHBUjtrUY8BYWvwEELH/E0FczTjmF3KsgR7qsKJzi2NzcJki0ZfSv\n6Oq6SMWfK+hyDrsGwjz1IEZGBtRRvyriJTW85geMeVj8P99ncuU5u30qGYKo\ne0CvqvVXAm2Lkx+guCcd8oIIaOzGqanY8Dd7A+gixHz/nX9ku6AIlq1wPadz\nwWf7\r\n=IhUU\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"4ce4a87465e51e026080d09b1ff865c7f384aa4b","gitHead":"08441223f9162b8e9ba3d7102005466ab09bcfec","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.27_1536879149774_0.7429810279752289","host":"s3://npm-registry-packages"}},"4.6.28":{"name":"kit-deploymentizer","version":"4.6.28","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.28","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"5c0ae0586ac0ec9591344d0482ed4863da8cdb97","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.28.tgz","fileCount":16,"integrity":"sha512-A4ThCD3JzAdPY388h/sk+NiQSaSIkpHOwCAoVdqBXM1GKAcRw9BGGSCE2/722UXqi9UkbXrFulwoRDu6L38Siw==","signatures":[{"sig":"MEYCIQCtSMe4AGSQKLH0a1Fn0jRpj8geq0p0IKUTGzFO8v0nAwIhAI7mDQPUR5qdA3Hz8oWLa+PrLq/DmRffNB1EA9KKZKnl","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":90810,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbtUgRCRA9TVsSAnZWagAAbfoP/3jwmbfAk9PFCs6PRUgK\nxzgPycrqaDea9tUGBDvhN1Hlgs9YB+/knrCj/BeLqN5v5+OWkUKrfm9dMRci\nUpK/rWrfaqrv+4gefLaP5Akclg2+8FdeInVV8qiitIt/+8w6avVpF1+4rd9Y\nyAXIo2WODERZM8t2e5xCjeoR0nWJ1Y5fYDUPsLTPX/2rphQhf5/k/6ulPk3P\nyWy21XyR7mCqKs8iTiFoMjpsOaQLrf/VWQzYAn9RMr7PzRXecyvcfo31TysQ\nGeHWWUwGLUQ2ceYeK4gOVVh0K9UJt+Fz30HYRE5pMGgxXOfpdURuBTvh5VzQ\nTbJuiugxj35CIJU2Twy75jS7UH0RFJNP4goxiQZbi/1x4mfEGdUJHDcEe08R\nX7ydKEAMAoq9DDGS6J4v8NRsU9uP+O54O4sYW3oQIsnIJOgKSjTxTsVXQvQr\nT/gkGkotSG38+OjtfxeNe+A7wUquvHniOXwGpsvSjclKswz6ZNNuniOu9M1T\nyBt0WRtCk/gHnztXJ5C4dcQzjZPDfFkwBci9fCMGKz2zncxXA2fkwJanVGEw\naWi7wYrgGS9K3Ah+NYBTnbZaWyC6SClAg4s3Z4r8xGO2Rqv0A+wRfcY0IzEX\n1qJH/JCrLR1DUCkt73V68JVBawI2TyQLoWqn9WwGEOpQtMYOSw+zk0P+mejE\ninr8\r\n=Wfy8\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"5c0ae0586ac0ec9591344d0482ed4863da8cdb97","gitHead":"72c80d60d3a577d406f8216e5337672765766b59","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.28_1538607120098_0.5001710116358131","host":"s3://npm-registry-packages"}},"4.6.30-PRERELEASE-EV-1429-resource-label.0":{"name":"kit-deploymentizer","version":"4.6.30-PRERELEASE-EV-1429-resource-label.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.30-PRERELEASE-EV-1429-resource-label.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"ff89f1468e59b8ef3099054a80ec1347e84749db","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.30-PRERELEASE-EV-1429-resource-label.0.tgz","fileCount":16,"integrity":"sha512-Xljw4KJnqAfMzfHDrg9TaNIsopauEf3REJvRdvFekp6maCphxqMcPo8uL857ZZvkVeutQ4eGW+/DNSQdQ12xIw==","signatures":[{"sig":"MEYCIQDLEyfiMIHPQ9OcEVz9QIE6SOVuXR0ZBzxTyzs/yxojcwIhAIc397UbpjtfszN1rxsBVqKeiOma3RaKAn+iNbPMaPNh","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91707,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbvn5eCRA9TVsSAnZWagAAHvQQAI//oISHuiMCCtE8NjOY\nC4RftphGS6wqN1LYQR5Tk5W/3pTk86Rh52R2mpWPulWXEkW3mOseKgdtK5wL\nxDtywTdHWKhdKUL+eQrH+7XCDsDhJ5iikL0nbTlb9DMVLbSRCfi2M95ewE04\nP+IEFILBm8uWGkK2QAKlYorn2LE1hFpn8ZeVp3jOXPjs70l4WovEAvIc7lhl\niHlSNjy7lP6LAJoyyulTWU+PfBS5uW7EGnyVh7y2Jw0wFx/F+aTnuNuaNp+y\n02ANfUjYjaxGIi3YmP+9m3N53iO3PSLkycXZjV/EDkJZujeLY9yxn5BtiBKf\nCAepGtct9iwyba3hIAFIA0hmsy+cxyrMwNp4p07ZgklIPw4T7rfqqPnt2qdV\nt6YbO/+05VTr3muyneyu6Yb7G071F9O/zyTIgTbEcfAdwbIR/Hy8GnY6jVRJ\nSES1l2mqaAObyTr618+GUsg5sdDpIo0uluoTxlUe275lH6PTp8kdRtHlan5d\n+PpMcz6BPh7pPhAhTR2ZFW6ynf6Jl+gPEf2DtrXTidIB9c9bK6nN7KFuueDL\ntGIIWSoLl+g8l4fLH6bLXM8zdloIucMlXl6aEoMvRC8+EvJnmmZiDARqxB+5\n10jeTOKYz6XdzuQ/7hSp6ipAssWG8r73yH9vuQ8qftU5MSZsCBlHCRcsV1cZ\nqqdE\r\n=iG6Z\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"ff89f1468e59b8ef3099054a80ec1347e84749db","gitHead":"8a5b12f05c4a7d82881e7312bb888147db03b3ed","release":{"fallbackTags":{"PRERELEASE-EV-1429-resource-label":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-EV-1429-resource-label"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.30-PRERELEASE-EV-1429-resource-label.0_1539210846184_0.32484063706633837","host":"s3://npm-registry-packages"}},"4.6.29":{"name":"kit-deploymentizer","version":"4.6.29","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.29","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"599a72b17a8eb2f5c51b3886181b6fa396d65fb8","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.29.tgz","fileCount":16,"integrity":"sha512-bYqucg+TrD5gquMduV+bWD7S5E+3cwlip40QI0VaK2frVTN7Q9YlCSAm2yagh0nbm8i4nwiXZL0vkvtSaouCUg==","signatures":[{"sig":"MEYCIQDu/IoJx5ORaNS7Nyf1Hhjnl/M5XWDINd2WmqNoG1bcXwIhAIUJ1NuG3tSBgdMQbzPwZ8LqnwXge4GQsbtTYbrwUa52","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91498,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbv3ulCRA9TVsSAnZWagAACwUQAJHpTlhZsVIVQK60jIbN\nuUk60ZwpC2+YHiNe+K6McPDEc/jKMPe7jwzqnXrO9+xKGYtMxhSYehYt7Gke\nPDUuYhhQ5eiwalEh8u3P1wweBGXGSCOhLiH1YHDKEfVudZ2Pb41A91h+wKiN\n3LfEjp2+ielRK+J9/jEfNYH28Gf5QjDU1fbhLLgCv4AhRRO1zheI5KOMGiGq\nMoYmLV0/mzwNs4WnAt6YsbVXnsG/IXm2BVCgQQaJyaoNW79RWO220LrqTA4t\n0l+7gAossWSiWgzuFVopDRsERc0vE8DsAtlqXB2VYijoiXCUUhKXHD64K5sT\nHwgmISqw6GZRpIx/JZ1s6HCKHleygfmBctHq0+J3c5Mp3HbDOUT/VvXNRYrp\nt6SdIvo849oJQtD5cQ4dwF0TXgUCVq3o1LNMWcs+D+Xli3fm5NZ2xyCU55nq\nB7+EpnC5Npv6D+evO3psXmhrk6tp0cAbP1SApNcrs1cbd+OaE4f8fiYJeG1m\ni0ByWkavCIonbS/5/9QEZf5/roRPRYqMgcCEwmQmILnNjamC7onDBH/eQXOo\nKBV7lgEr7+H2UydZ2LOzygzuBgEx2nv80ou+Ue4xVQBBDGLYVStRT+m9W5+Q\nF3/XOZTmVCM6J6VzwWBKdufdHC62/KWH6dnyeH3VKB91eGEmRNuaQEXbWxsQ\nP3jo\r\n=NkyP\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"599a72b17a8eb2f5c51b3886181b6fa396d65fb8","gitHead":"3fca81da52a8d2bf9147db1509732e462c4ad067","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.29_1539275684894_0.949464098179061","host":"s3://npm-registry-packages"}},"4.6.30":{"name":"kit-deploymentizer","version":"4.6.30","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.30","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"377f47b549921a1cafd77de16692a87b8dde0158","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.30.tgz","fileCount":16,"integrity":"sha512-2zaC/ri6CiI2lZ+AZF0kMLfwB9GxjzIIUy8rxhbAEk9sAcIrMWqu7p0tL9/NHVzzG/mw7Z5XcF9IgbrPxzlITA==","signatures":[{"sig":"MEUCIQDPaLjku3Y4Jy5k3ebtLM4cek/8bf0OhmZ5QS/wvXQivgIgbATrw66G9BQIKvaMil3oWD7dpBWCd8dj7onm5W4ZOTI=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91498,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbv3zhCRA9TVsSAnZWagAAsNUP/2hIIDqcnSxqpEmnlBZv\nQP2PKfYiCKyGoj2ubuoqUglAvbOxgLbhN8NSmAsPILJcspPopz11D9Ols77d\nNJTtA1iCihAgKKqekgwyOPEcJbS3rQ6pHQ6GF9YwpsODoRKkorwxDP/6CaE+\nyXE0ttsizu29eOpxX1s3c1ak5U3wv42tyFtAx/iKyi7m2jGNfeKgHPabGGiU\n1SZe8yF7p+C2Ec30tnE4OLl9eUm/YjnXNOinI+xROJ/C97lVNh84seNfp8ky\nKURA0L+jCGdNnFUZFPfYH+0pFtdh8kgO6AQxsh7kjZ5l83+CHjIKusD734Gk\n4S9liVr5MIKXUihLmPn9YAO7RF/XTEf43bLbLGpVPfg7baUQ/kaEqoT8JLCB\n67XgOmeLpmhiGkuL93jSCe3JtLikOC2UKL8Bpu96oSJd5Wc1ikApkkQkkaMt\nZ8hAEBes1dNHXJ9GtlmxrMO5bEoScITDGH2XT3Vc5PfiQfyMfADfKz26Rd+o\ntCLkRd12BSBU2hu9yjZ2I/FCNOOxndVFhZlOkyJ9Ha6aj1VCwDx6Mf1XC3iT\nzx16ISp0j9uKK0357ORHNegBnLQAmUp/bMSb2JewgWZ/q9fGqxZypYMeREA+\nauA+heINmnJqZGkyA4oYJH9EBajyplvb0Nc0dyNZ2OyXzsi8AVHfCvcUE6Ux\nFGj7\r\n=A6rO\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"377f47b549921a1cafd77de16692a87b8dde0158","gitHead":"2b0d686ce05a90be0ddbf5bf981c2a528a463faf","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.3.0","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.30_1539276000725_0.01689941087606961","host":"s3://npm-registry-packages"}},"4.6.31":{"name":"kit-deploymentizer","version":"4.6.31","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.31","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"189c9efc6463f75c457cff4856a17b9646af1094","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.31.tgz","fileCount":16,"integrity":"sha512-7iuiD6TAQh5hUjqGE8asg8fOgtCGFwScWFTC1Cslmlw+rfcTGypRivv2W8YnWAcnP0LCDWp1vZF6EWRA/mrS7w==","signatures":[{"sig":"MEUCIEQyX5+8KSeA/4pKE/BmeqDIbc/YU/k9G0VOkmr3xTnMAiEAoMx9II3n+fTSMUtSQ7V0tOiFFRsmlPMCn2tfCQeoN00=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":91499,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbx1hkCRA9TVsSAnZWagAAmgcP/3XOdphh+h5LEZfgtQbH\nQpJcWek3b2VwecmIy9Cw8+lC5+szlB1ZRCV6cFSLo6KHZxbMAsn7wOLjWzpO\nxHmF4VbH3y/c+3vNwZ04+xFonwGPRb9UcJ83i00H/GOaHFzPFUea657tXumG\nduRj0iItzH1A8ezkFlk4GG45iiC3q/vyK465Z1NnSATlHY3qEvkOHPMlIvC3\nKTYUpAgJ6pR544z4M/rhjYhzsxVq9pecW2Jkg8Y7ha6+t74r1LDoyid5Q1cx\n2gVT1AjUcONdgMU0r5QMG084TiIgKB+szSXJop0N0/4ZMl8YsN/gLjTD75JF\nzh+/kE2JxzXRRSiCvkzBs07V5bBtSMiBu+bR1TJmg62R8eiSsudAlgTabo2q\nCmIsd+bvza9GP5sPtkS56/NB+msMy7LYTO8cWhkfAH4kalTfT/LjcA/bpKRP\nUQ5y0Zm72GQccEotn8Ab3D1BghbzqNCreJcFYnF1oySxmbs46Zou2ZP4MbD/\nVo6LkJDSMe6yxNOhVSD2w26H9zBdFXAezf183B1aKjwrHFX4CzNDqtQDVaay\n7nN4zYAfvpwz+bJIf7xS74mPL2HODJzV+AURJTz1oPOR1MOKAdMIiF91IAqO\nC+jEbx6WsJTpUYENbBNZjEmlO7N9w+k11PRLZbFcIfpYwfVPhDiF61z6Qh0t\nx6bQ\r\n=Wlrs\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"189c9efc6463f75c457cff4856a17b9646af1094","gitHead":"c818f9a7996fa89a7d2c3be6838704901705b9f3","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.31_1539790948044_0.6491383228811329","host":"s3://npm-registry-packages"}},"4.6.33-PRERELEASE-EV-1579-git-ref.0":{"name":"kit-deploymentizer","version":"4.6.33-PRERELEASE-EV-1579-git-ref.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.33-PRERELEASE-EV-1579-git-ref.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"01b4a6c90c9625e644393270c5ca5eab03c836b0","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.33-PRERELEASE-EV-1579-git-ref.0.tgz","fileCount":16,"integrity":"sha512-kunEcbqTXwdF/cUfLL5wiDqCX5zVlTSFHGQzgeelDoGN46vAVx7Waor/DvAeW7zyvs1xIX8p7St6VrnfMOjO8g==","signatures":[{"sig":"MEQCIEQILmMJLcUMCD587Ws+pjVnUQzDIO9y/khQP4ushirjAiB3ETvwmybEtAbAuh9ZQD/6Sp6XsE2SnV9McZoIOvqhAA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93210,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb14bwCRA9TVsSAnZWagAAjq4P/33AKZCSaDxE/YZx+AMY\ne+jCK1kie7yoOFjI+qGfscIoXWUDs8TtvOKhpNY41E6nkjeTBWdddEF+dd1c\nTph997UQ2G0S9gqjPz9TZj8F9z/kmwGvSvDVSij2cqWBJr34IKuNNaZMpHME\n2vzEvkwiDg3JMygJIVWZSOinepjK6VVyNVsFDG2eqGStqub2s4oH8ytWHmqA\n0BnelS35wr+I4uyf0uexvuYhIAa2SWY4+TBUy4SHH/VzdaxHxwgffypV8MFR\n9VwIJIk/3sZgzx7LWG7pTBtyfq9DJQqRqi2KkhVSaBN6LD3A8YmAH8OaEOZc\nc728SjxxaM84OHSsEs/r+EEcy4yIoBgreJxpjiCtMn2sP3MaRLmJ7fTxsbv1\nen/N1JP8Mu2MdXfUzKOrbXuRTwqKy8keAqdYhs9EvWRWzrTgjDLCKB648Zx6\nr5aWSkv13RXox0+PEl9KxNy030thSaaQyhk9zP1AiVYLAHetRDkQS0URsoWZ\n09joRKEyMQShnIvykACQv5xkYi9oGN+Rmql0GjNJq/cUtsPHxi+CfEyWKgye\nreCa421fa7APD6R4anOfw4mQXHqqnl2SEkBultZryeMzvGV2tQcfDaJ9P83U\n58LzxXHGApA94jVAzMjGLd4NNC+FkzFe80HED/pv7Yz3XrJJNRz8jOzfr87l\nMq+h\r\n=qUlV\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"01b4a6c90c9625e644393270c5ca5eab03c836b0","gitHead":"3849e1a08eb356d3c2b4153f11fe33d769ca2010","release":{"fallbackTags":{"PRERELEASE-EV-1579-git-ref":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-EV-1579-git-ref"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.33-PRERELEASE-EV-1579-git-ref.0_1540851439377_0.9972667310382355","host":"s3://npm-registry-packages"}},"4.6.34-PRERELEASE-EV-1579-git-ref.0":{"name":"kit-deploymentizer","version":"4.6.34-PRERELEASE-EV-1579-git-ref.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.34-PRERELEASE-EV-1579-git-ref.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"3c57a170b947ae07b3770aa0de8f1eb52227a6b3","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.34-PRERELEASE-EV-1579-git-ref.0.tgz","fileCount":16,"integrity":"sha512-MSq/ZoBnsUrxDXNXgjoDeuLY+up+jnGBkPk35gVYck0i6P9H6vxF1vQ5EJF3V54lz2Lox9RSwfLd+h9mXRfWaw==","signatures":[{"sig":"MEUCIQCn60e6tgqldvUXYYdKy++u8eds7KHwTX8C2b5yVNekxwIgRJbjpiQNIbszhgSdwEcgxW7QBuO1k2blSfFbZAKpmeY=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93248,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb14d/CRA9TVsSAnZWagAA5QUP/0QFezMJJSGW+GbO8Ee2\nA4LUQj05Q9uu30wid9iPjpxLkmiOMK+Pwf8AbTVHhMSPR+hWMFdRsSLMxNMH\ngr96tDIRjL0laZoXgfuJe6/9p+AFBMG3+0WEcK92PSsYZ14hJmb6S8qwNsns\n6KgvF57D2whoSOdhm26tgZ4aNepiP8/d4eKTEH4PIy4IuJWzckvHevbwdVOG\nPO1p5XWdt8g8GhZbXfGijh4omaPYsmMdQJcom/N04gxXExMWnrGMu+X1kRuL\nc7KQ3zaUGCe1qey/JMtjwrScnIKF08RCi9j7PG7yUYLM/vrBt0leWofFVAz0\nz1/py28zuJ8ZpAQwmJRYZa2EznIoZSVws95Xz51Cm8h5ekFUq7JlnJCWF5yA\ng/mkTHdhh6DToUg5eLI5LylraRg+ryAdtagk1eO9seS7C35qkiiM5+ywSRr2\nz8E2vwPzMqYb2axaznqvgpz92gvq7BUUoqFPY9d0SIz4R6guDjBscMunI5Pz\nMMCPh91G9ehXIqSDT3GFPK+RXP5e00U0SgvkOE9uIuTj4tRZFD30qqIrILNH\nf7W5PWBQTLTy/dQFjUFBcX+Ea5AmYuvjoEorswf9cVKBahrDW2O7L3CZeOmu\nAPY0PFYnGePsjjpxdd/1LailV4UfEIw+n1NazRxVDbMKvigRECz+U3zjymL0\nSF4Q\r\n=An8+\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"3c57a170b947ae07b3770aa0de8f1eb52227a6b3","gitHead":"56f9718e5c300444036e1ffad3f38fce1da84f11","release":{"fallbackTags":{"PRERELEASE-EV-1579-git-ref":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-EV-1579-git-ref"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.34-PRERELEASE-EV-1579-git-ref.0_1540851583014_0.1950115413804523","host":"s3://npm-registry-packages"}},"4.6.32":{"name":"kit-deploymentizer","version":"4.6.32","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.32","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"8f267faf4cff67b0429a8191e8527740ed8c09c1","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.32.tgz","fileCount":16,"integrity":"sha512-bIS/aW3zXAtfQM7dtW/Bb7U+V0rM8E8CorZrl/FBTCnd0Pmzn6cB14CrcXUNtBzBSNqy4BpZ1voooKDiGcbnYA==","signatures":[{"sig":"MEQCIBOS50l3y71IL2Me6vqHJ6gjVxVl52Lf1We33X8eqSRDAiBjYFbLiB7nMdOYK400D1RGXjcg0/URqFuUppf9KDrL4A==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93060,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb14yYCRA9TVsSAnZWagAAfdwQAIME8CoyKfus4g+0oDzu\nQetNnlj/cEK1sVWKN8jF/WlXUkWY0gv789iTJ/M71sD6uVO2mKNP4QPlXLzK\nso/o0jFWldIFzIGoFwK3Re2aqxjuZx7v2MXZhogkbYtQ6mSyd3VPMq+B7AbO\n5KdK4qYKgcHEgFTqlIGBm2i5e981LeVAQLxK7nrUNbIY1bDXxq2vd2YRfNyG\n+ZzyL+CjL5VH3KTFAlMQc+GHHWwc5VHS2DMBXkgFJ9KHhB6DcyfDZ92BZUTK\n86u+BOtNn96pOY4P2nRWedmASuNhmGiCO4tqoDrvBrxvLGednL3K/cCVzuOQ\nqMDJ3scPQ7zRzSd7Ov9kDY9Z7MzEn6r7Ni7Zvdnvt4jJHB9a7M2xrKKf8hoc\n5ZbuONKwfUPH2vffF+RxErMhNmxIKRelzrFNfa1nTh0ptdLgQVGVhONFtB6/\nBz4XH7Ushk5nMQqXJSIVnJQnPcUfKLzbgeGpFwENasInTjQte0bGrI+jqcxw\nGXCmDXhRFYnXHAQ22XoyC6V6EhHnk/6aedOy60bJM3K3nUENuoMMBYu9vbiW\nR0xL4zmM55r6e/h0iMMQpWhWjqB7jtyeTmQfxRBb3wWAE7KSVp8lpr7PHd+d\nuHX6onmKJB0RNl26Y3DOMuZnPn/O5Ug1qhJ+V8d4LhDF/UDWOdWu7YVQuKTD\n3ioo\r\n=HCbZ\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"8f267faf4cff67b0429a8191e8527740ed8c09c1","gitHead":"507610407bf7788111464ce3fc7f7ac491c995e8","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.32_1540852887943_0.39748189601019956","host":"s3://npm-registry-packages"}},"4.6.34-PRERELEASE-partial-content-err.0":{"name":"kit-deploymentizer","version":"4.6.34-PRERELEASE-partial-content-err.0","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.34-PRERELEASE-partial-content-err.0","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"1737d8d0aa4e2bb62dae4a7e7ea9bc88a5fcb0fc","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.34-PRERELEASE-partial-content-err.0.tgz","fileCount":16,"integrity":"sha512-LpvWjxFErpnk2bxXP1iPTg/GlF3gljw0LqJ2FU4GVpBkqZ39x7YBRyXHo5jBoeM/oCQT4mRfZyRsIEGo1SA9hw==","signatures":[{"sig":"MEQCICsYSINpKpXP1fJ/VltI3v2rQlxwk6VnrOHy+xQP71ndAiBCEnac/XMwnSUPbRK2y9mt8lcu1Vic6IrQxTe3N2/FuA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93515,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4JHpCRA9TVsSAnZWagAAoL8P/1nJdeq2h671IIWlw18y\nLUioGLQ9MJsTYkaTgUEPjjfTo2Qx5v5wt6NnZb9N6tEy6iaHJBYK/ygUoG8Y\nbwKinYHUHV+OJcdTYori5GAl/UlYazY0OFOYAparYolo1Xy+A7IeD7wkMy5K\nPUp21tr+hW7DknDvSyER3Cvp15Lc0Aw5c+b1MgvBetC7hQxFS4TD2NagMmU4\nDPvDapga+P04iLU/N/nfjBvAJNHr/Jh9QSsIjDQomL52rjRkeSxKUwkCHFYW\nPLo5CfGDLLocUBceOBV6fJvoGFmsEjJwIQEXDNM+Ulu623GPT9Qgc9ESbSPG\n18d1ZVFx51LC5+TpjAMB7xQQbCB8IwoMz0XZ8xVLV5YY8YJ2asuid1ehXodJ\nCA1esQtPGVQZScLIcv/pzzF79MkUpV2iVryGgM1kGRYNcAZLgUN3KfAlPKrv\nkn1tqr5XXay1oy0sUPQnxiITa6Sb4vrtxDH8Sz+2ZDN0Gp1xgXkqB7EMFTCU\n4hu8Q4kxqT+EnSxU1m5pApDNr6l8DoWDCJMylQ1/SrfCECwOeEuIGPz6+GV1\nYs1NDjnN7HGSB6suJsVcModADHK1oMH8TMGdb6/Ko9Y04aBmKzWWcICqVolK\n4lUbu0I0BBgf1/kRvSwrCqn/w+cPvcTE9iNaeyanRaDSK9SH01GMme24CwN6\n4xgi\r\n=pGqm\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","readme":"# kit-deploymentizer\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","_shasum":"1737d8d0aa4e2bb62dae4a7e7ea9bc88a5fcb0fc","gitHead":"512e9aace7c49d0a9995a5550a462bccac316975","release":{"fallbackTags":{"PRERELEASE-partial-content-err":"latest"}},"scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"publishConfig":{"tag":"PRERELEASE-partial-content-err"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.34-PRERELEASE-partial-content-err.0_1541444072605_0.06327939796320603","host":"s3://npm-registry-packages"}},"4.6.33":{"name":"kit-deploymentizer","version":"4.6.33","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.33","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"05674a2f2a6943556e7dbd99a71eee5db68056a4","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.33.tgz","fileCount":16,"integrity":"sha512-YAIs1KhZ1MfbQZIEcxB+yPPy3+kHGVxzf5SAO6+KW/RW0nVr8+3LPEF9s2N7v7lwZLW64psIBNsAct/pSK4Ovw==","signatures":[{"sig":"MEUCIQC75G6P/aQe64bQ1IIWZqAjkA4o6GKWbKZSxjuQ26oeeAIgZHAG0r213UcMtYww8aPkCVKrQ28s0Lsk/Kri4ziEKis=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93315,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4Lo1CRA9TVsSAnZWagAA4p0P/iFPLr5N252AoNGEznHf\nJfpkG7qPAgwW1L9iQJu77fk9BCVFZAkhm8QGm3oi4VPfnXueMKbvANLrdWbM\nFS7lRlzNH7S5h/jAlrmgj5nf+HaitdDfO4aJw6hWeghBtNXK+6BzwPmlGxet\nL+J25ZNOhe3/arhXvxETx5khP0hvA5fncWfVK/ff1n5K0hPiqu+fp3IFjtx+\nq+CLkhlmz27+Ckjhclz6UHcMFrj7bFHPvZ27eSXtfIhBhBux9Z5jlOsjWOMZ\n5f+Npbuo8p9w79tVzOhicGN14V4Ip3q2m9iZ63+iEUh1ciq3p1l+lpMgezpQ\nyxIOIeEkQVb+el2ZaHjmYc3l1nmyy4Pfn/4yHrfqh7x3ACtypmISs0hq2c0l\ng3yCNh/q9edW6iBQl+7hYuZ1eyGNMXJ8iG+R+XHpZs21bH5DKf+UGAAib1Lt\nJCEVli6vfse6rS4tsfcui/ItTHzpYEhEwvz5MAoNajdHO3XkcXiZUs+uu9rS\n1RvKf7/hzZ4B/TFP0jq0JY1k0iQIc/FWMVlaezbImHtsEXjyEPzarQrqt1Gw\n6gRIFFYOrKXUDRfroRNDPDm9ZucdXb6zpIUpsmko/M3ksvUdah3pMPPrpvfb\nStdg+aFf4tZWrxeJF6ZzLChIEhP471vsmN+LO5b0uztrLk2/gTynA66D7esl\nv9KB\r\n=MIqD\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"05674a2f2a6943556e7dbd99a71eee5db68056a4","gitHead":"79c0b3cfce8a218b7045ce39048db500bf693e45","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.33_1541454388031_0.4785176158355249","host":"s3://npm-registry-packages"}},"4.6.34":{"name":"kit-deploymentizer","version":"4.6.34","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.34","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"sumcgreg","email":"sumcgreg@gmail.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"ba5887b658265be933a7f33f92d8ce3f5b494a2c","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.34.tgz","fileCount":16,"integrity":"sha512-p6tooY2xRUyeBtnQqcAliAfnfE18q0NV3pBa8xkU+sZFUhGcuUhjWU8y1fY+Iyx2A92vwKbSFCpaAwetmgxSYA==","signatures":[{"sig":"MEQCIBMD5dvl+xysn4G+tKVWolE3NWVSG6spt+RfpZx8wWJGAiB2lj4bGmht3UpXUW2TfAYTjTdqatjhEdltwk7esj6iYQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93863,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcCuZHCRA9TVsSAnZWagAA5MgP/0e46D+XOG4R2QYoc4Tg\nHFVuNbK9i0grWdKYHSyVNDu6SyOyoQGx2D6MEp28bSEnFOqcyeCRhlvjR/Hu\n8PGQt+pi5tSE6p8Gn0LgiDPxRty0HTEqtUPA6riq1TcogQGDPeg+53+Y+wBb\ndRe+zR2l8RsVx3+xOjM0JDnbZdT8bagQs99iHQDgN5nPloxllN8GCXZdpHda\nH1n1IFA3D4grE0hG63LdkNWXFnS6CHv5trNG5hK7u76wc6FnV6FzFCeNkWEr\nrfeVimdAm4EUuvZAwyGypeTsTjeK0SZ39F9fo0yN9HGol/iFo7DFXLc4lHmU\nrIXP/+Uc6dXuxsDu8uFOsRWq46tywsjOeYhg3x2/1x5C2lHQCZBb84zpUBkv\ndz+8/7fg166tQjWsLwdfBT82ml519PYVMBLrxTuPrdHPMQm4AgPGzfisJE3R\nCR3v2YAEdWWzWqgmynSC48xTOukV6sBpX9dwX4sSjAJJhP+F9rkQXeYVRn8g\nsWEN7Yk/LY+m88LPVu67Po2J8jk/2TUafQmREV3HpjhdRe31OHcKVkLgD9Q2\nrxEaW8VSTsvbM2RcZr2vtKBMpOXm5+H3hz0Sfum5ale5dRLan72AhklLy2uD\nbcn4SUYQfxNaKu6ge4AJ0LcuLRvF7etqogAsrN91vjaie65WtnPZTcT06/AE\ncVuh\r\n=ScTg\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"ba5887b658265be933a7f33f92d8ce3f5b494a2c","gitHead":"a5ca15bf31878b6f9b54641d66ba10033ffd0eeb","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.34_1544218182364_0.5287415100659325","host":"s3://npm-registry-packages"}},"4.6.35":{"name":"kit-deploymentizer","version":"4.6.35","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.35","maintainers":[{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"kimmajor","email":"kimmajor@invisionapp.com"},{"name":"manute","email":"manuelalonso@invisionapp.com"},{"name":"mike-douglas","email":"hello@directive.io"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"sumcgreg","email":"sumcgreg@gmail.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"aeac2661deb797e040d871018233af26c7393cc9","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.35.tgz","fileCount":16,"integrity":"sha512-37qtK6Zky9DjoXj7AA5LK6S2FhYEYg9zevn/yZPd+k8WkfwT9MxX1WSJ5pN3zcRYas6JJsactT8+DaCIqudA0Q==","signatures":[{"sig":"MEYCIQDnD08e2wsydmW9XkxGGgbqk+Ec5m+3cRUUANC/PVqxNAIhAOc9CwZJX9qjAEro+Hrxc5DeyPCnX8LACE2CUbG4mqEg","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93947,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJco27dCRA9TVsSAnZWagAAO1MP/RjWRCwfGGzp36WWmzsQ\n4NjQ10Rs07ikSQcIm9StVkwlYGj3uDl1RSRc/QUVMsylkG5M43XZTRnqFkw8\nk+E09GqACRDIJVHPnEi8ARER8EguW6/3QfaMBnx2AqWR/ID18VF7PW1GIYwJ\nGrBBHM6HKtg+YReCchdHi+yTXoXn7D6KgroM72kuGJBR4EGh2wSm3u41j5Q7\ngic1NTJGeYWIPyPH18znRjoi5O3LhmkwoZLDdaqy5p9thdIq00IJ0BJzPzuk\nn6NTLw/HjeYxScN1T7qah+Vwz/zMFLK7DfY8qY+Zg+4nQqyQ9Jx6d6Anbb3U\nlBpiyIZFjl0g4BF22jAwxxRwuqHvLajDOsfayMEd2SXhMgrdow5jSsN7livN\nA8e4TbXsMfOVTsnfuSDd1ZQ98LHh62ISsV1jdlXDjcY8dOzy533Z3XeKeVQk\nssqeTjyFoMacUf6L6p0OC6TBiKuLkkGa4OuCPKb9HvCZFUcRCcq6dJ9HTuYR\nb5fPqhQ5clRlGwY0hU0wpbYSlcPKFbqftD+Okfp+lWc1xgXgV24gvgWyoPzf\nGGE+DFIQPPSBcw8zwdCfZ4fjdjB/8TvspB4zMy0k7MlVTJizr0ftRAqmt8RE\nbywC/dgG5DfFwRI2WY+urtBH1zfiw0aKKyeagLnAVak1qJWrmLWWFntZZUld\nabbg\r\n=hn2D\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"aeac2661deb797e040d871018233af26c7393cc9","gitHead":"5246cd631e85b801aff65451a6361954f54a048d","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"deprecated":"Thanks for using it but we will no longer support it","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.35_1554214620513_0.17404140025217418","host":"s3://npm-registry-packages"}},"4.6.36":{"name":"kit-deploymentizer","version":"4.6.36","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.36","maintainers":[{"name":"adamyonk","email":"adamyonk@me.com"},{"name":"alextreyger","email":"alextreyger@invisionapp.com"},{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bee.wilkerson","email":"bee.wilkerson@ymail.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"emilygoldfein","email":"emilygoldfein@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"icirellik","email":"icirellik@gmail.com"},{"name":"idev","email":"devin@devinschulz.com"},{"name":"ishotfirst","email":"jason.lemoine@gmail.com"},{"name":"jakubrpawlowski","email":"jakubpawlowski@invisionapp.com"},{"name":"jportela","email":"joao.portela@gmail.com"},{"name":"juansalas","email":"juansalas@invisionapp.com"},{"name":"keywordnew","email":"manil.chowdhury@gmail.com"},{"name":"kimmajor","email":"kimmajor@invisionapp.com"},{"name":"luizfilho","email":"luizfilho@invisionapp.com"},{"name":"manute","email":"manuelalonso@invisionapp.com"},{"name":"maxnunes-invisionapp","email":"maxnunes@invisionapp.com"},{"name":"nadavkaner","email":"nadavkaner1@gmail.com"},{"name":"obensource","email":"benpmichel@gmail.com"},{"name":"privorka","email":"privorka95@gmail.com"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"sgrigson","email":"shawn@invisionapp.com"},{"name":"shell100500","email":"shell100500@gmail.com"},{"name":"sumcgreg","email":"sumcgreg@gmail.com"},{"name":"titaninvision","email":"titan@invisionapp.com"},{"name":"tomashanacek","email":"tomas.hanacek1@gmail.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"7a2a2c922b4e870e6a2614f839a44f3062136c6b","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.36.tgz","fileCount":16,"integrity":"sha512-KZY5APV3vfmexCV+wh3BJPnciZRtJ8yYQsp0VbKcq3ECc9FKvHhYPuv5apjbVvE33/WzunGE72zVnn4Yst2OdQ==","signatures":[{"sig":"MEUCIQCa1x2ZgmRYHsi5RmllKd7ttpmcpaRZRGbDi1wbGWapyQIgQTzbbq5sQdaObK8GwtJkJQNOdi2NLUH9RzAXUH/qtoI=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93947,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdn2n+CRA9TVsSAnZWagAA7jIQAJHFlQ3dAffOvtzwgnT+\nujmB+qa7SA5Y9KuHhadBruEdE+zAvizVCMtmtsvg5Y3QAtK3Dv4AqvDND0DL\nNI4wIPpX4nm4AIzd0iSV3Du9/c33T6icZ66P/t4av6CM/GnfOUGnM3lx/6ZV\n2FId0cnUdCdPMPj6EMRcaDrHHiXSDd8B7vxa5xe8f7RcmyM0BAzLOVR4zpeR\nr2gF+nP9i+X5yVgqpMx7/94LfS83ZOEiQhMdeRM9S2nEyljpnLxg8bPSiEoY\nJ2hD9JyRps/eFRbiSYZX/mYBmD+QaDfwQcU7PG+r5gagF6AVIEfxHfebj+E4\n6tKOPmsFCv2oeOoi6KQDNembXZs/IPdpjjkCTbeAKxberJ9S2b/N+V9IG2co\nsp80+IAnUVKlHlJOY76Gg/LzABWWVOv7sxTVm4Ah6fGsSoYHkNoUM8D2tETf\nWQAKvVn1X82wtXpCfMkteQeTZ+x9cHxPg7hdfTClnpz13dxB0Bt5sY2QuRXl\nEEqtGwe7gcL4uCuKWwIkKzonEYgs89O7h8k4qlY/yMldVG2Z363TrMDc0Xvn\niaPGrnLcbCB+FSgZ/L6vsNw0XW+m9caV9OayKxqAsxBZkKc3ooSaMfANz4T6\nIR1i4D4tktDLt1IORTArcsWYQZLnUfa1IRG8myWNvJE1FCYKoE0xryeO7n1S\nqWaf\r\n=NKYW\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"7a2a2c922b4e870e6a2614f839a44f3062136c6b","gitHead":"d92dc8f9093682f9f9bc853ab26fe98eab1083e0","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.36_1570728445498_0.8642815909315056","host":"s3://npm-registry-packages"}},"4.6.37":{"name":"kit-deploymentizer","version":"4.6.37","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.37","maintainers":[{"name":"adamyonk","email":"adamyonk@me.com"},{"name":"alextreyger","email":"alextreyger@invisionapp.com"},{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bee.wilkerson","email":"bee.wilkerson@ymail.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"emilygoldfein","email":"emilygoldfein@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"icirellik","email":"icirellik@gmail.com"},{"name":"idev","email":"devin@devinschulz.com"},{"name":"ishotfirst","email":"jason.lemoine@gmail.com"},{"name":"jakubrpawlowski","email":"jakubpawlowski@invisionapp.com"},{"name":"jportela","email":"joao.portela@gmail.com"},{"name":"juansalas","email":"juansalas@invisionapp.com"},{"name":"keywordnew","email":"manil.chowdhury@gmail.com"},{"name":"kimmajor","email":"kimmajor@invisionapp.com"},{"name":"luizfilho","email":"luizfilho@invisionapp.com"},{"name":"manute","email":"manuelalonso@invisionapp.com"},{"name":"maxnunes-invisionapp","email":"maxnunes@invisionapp.com"},{"name":"nadavkaner","email":"nadavkaner1@gmail.com"},{"name":"obensource","email":"benpmichel@gmail.com"},{"name":"privorka","email":"privorka95@gmail.com"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"sgrigson","email":"shawn@invisionapp.com"},{"name":"shell100500","email":"shell100500@gmail.com"},{"name":"sumcgreg","email":"sumcgreg@gmail.com"},{"name":"titaninvision","email":"titan@invisionapp.com"},{"name":"tomashanacek","email":"tomas.hanacek1@gmail.com"},{"name":"vickycouturier","email":"it@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"25f41374017d2390686f598423e4eb08a5652212","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.37.tgz","fileCount":16,"integrity":"sha512-6HeuDZtTZTcoMUOSUd21Of2118nJ0lwWQa1iYJIpqDGKczeiV9klllODf6xY0Io5EciUEzj5hUIe2KRJHRVH3w==","signatures":[{"sig":"MEUCIQDB+d+je23nI2KKygnsJFRlGY/1g2I/RH2MGzeQKSxuzQIgDsOlXzBbfQ68qyyOA1xO7rtZz15x4gLRWFev3sjKyLg=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93947,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdn29SCRA9TVsSAnZWagAANAEP/iE7p9JNRwfSkOST/ftS\n+FwEtuoFBDB6xhV8CbUWtU225gS82bVrem8Kwtlc0+SCQ8No8awpuf6CydPH\n9fB4SYJ20oFDsml2TwhC1pKClRcV/sCOW7Qq2dg7yg9oe0L9IgJUnYznmw/R\n5PowPt8lUoTyQo00vuM1OjnoTwWWQBCTCxNg29eNJLC9wTbYE11cXhNbnuD+\nxu4pjg+r7Mtp63lKC84Sak5UNd++RMHkYzMP7wH0sB6pC9plXZWya1pEdrpM\nN9mu30kP797QYCwe2/EbDrszDZ6m042SLbmUvPJkl1BBVdlzB/kPDx8lKL2i\nvLQMnEe+MENddjum63Yn8YEZw1tM2j/zy4aax5J595h2h7mmnOiESha7Hiut\nwK8Yj+1nsxJcLDjIYrdWDhAEp23rL5foJCEzWtbl7S7KDYhvB4pxFVtO8YsE\nboFJH6eKz9tbQ/GDb29QOLrKEBqs1skY9PeHw6dDS9QU5rnz/zz0+4TcIm0l\noYQMHzuwZEDim6Q35rqcwCGPlA9L6pYgPJ2dLKgH4aAIBjYZbglX6ul3nJUT\nSuNr5FGvtLegk+1BByxEi/XjhS5wfkotecQ0+dCD5oQIbaeAX/fp+bggpRQr\npALLeiulHnmPejzD6xyvErUcmG6j0Oh9Wp5YZp7f98Gq1hYHn16NUQ+eXDlW\nObqY\r\n=6jcE\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"25f41374017d2390686f598423e4eb08a5652212","gitHead":"42563c7fffa1afd3c4e7a8919caf6008d18ea4de","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.37_1570729809946_0.9991120180992461","host":"s3://npm-registry-packages"}},"4.6.38":{"name":"kit-deploymentizer","version":"4.6.38","author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","_id":"kit-deploymentizer@4.6.38","maintainers":[{"name":"adamyonk","email":"adamyonk@me.com"},{"name":"alextreyger","email":"alextreyger@invisionapp.com"},{"name":"amytroschinetz","email":"amytroschinetz@invisionapp.com"},{"name":"bee.wilkerson","email":"bee.wilkerson@ymail.com"},{"name":"bsana1","email":"bernardosana@invisionapp.com"},{"name":"chesleybrown","email":"me@chesleybrown.ca"},{"name":"devops-team","email":"devops@invisionapp.com"},{"name":"emilygoldfein","email":"emilygoldfein@invisionapp.com"},{"name":"erutherford","email":"erutherford@gmail.com"},{"name":"icirellik","email":"icirellik@gmail.com"},{"name":"idev","email":"devin@devinschulz.com"},{"name":"ishotfirst","email":"jason.lemoine@gmail.com"},{"name":"jakubrpawlowski","email":"jakubpawlowski@invisionapp.com"},{"name":"jonathanharrell","email":"harr041@gmail.com"},{"name":"jportela","email":"joao.portela@gmail.com"},{"name":"juansalas","email":"juansalas@invisionapp.com"},{"name":"keywordnew","email":"manil.chowdhury@gmail.com"},{"name":"kimmajor","email":"kimmajor@invisionapp.com"},{"name":"luizfilho","email":"luizfilho@invisionapp.com"},{"name":"manute","email":"manuelalonso@invisionapp.com"},{"name":"maxnunes-invisionapp","email":"maxnunes@invisionapp.com"},{"name":"nadavkaner","email":"nadavkaner1@gmail.com"},{"name":"obensource","email":"benpmichel@gmail.com"},{"name":"privorka","email":"privorka95@gmail.com"},{"name":"scottrippey-invision","email":"scottrippey@invisionapp.com"},{"name":"sgrigson","email":"shawn@invisionapp.com"},{"name":"shell100500","email":"shell100500@gmail.com"},{"name":"titaninvision","email":"titan@invisionapp.com"},{"name":"tomashanacek","email":"tomas.hanacek1@gmail.com"},{"name":"vickycouturier","email":"itaccounts@invisionapp.com"},{"name":"winnietong","email":"winnietong@invisionapp.com"}],"contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"homepage":"https://github.com/InVisionApp/kit-deploymentizer","bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"bin":{"kit-deploymentizer":"./src/deploymentizer"},"dist":{"shasum":"67eb96c45719766d9d8881b3f219cc4203906a63","tarball":"https://registry.npmjs.org/kit-deploymentizer/-/kit-deploymentizer-4.6.38.tgz","fileCount":16,"integrity":"sha512-vdaxaqAmTesFn+//c1EAe2vOgPQVD64K12Lpo+ACt+nfWTfOTfP2YLGyxNvLcF67ID2aZp4si4Fb17uDOJX7QQ==","signatures":[{"sig":"MEYCIQD6Uam/rErk3FLzFxwftQ6GAWB1nQIRm2mMvIuzXZvW/AIhALPBcu7xp+j8AlXmGjaeUrwTFHgDPSSRECQonE59xmPJ","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":93947,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJd1WiSCRA9TVsSAnZWagAA9ysQAI5kcSX8r/oePTk1xYtQ\nyOXqzhjuYNL5+pWcZ8NkZzgKSRyCa2ODcc7Nu9Tq1xu6xJPR26JLCkJxKKW4\ndXWy9pDvQIIWDTLyOpLpg2A62kxXl/a9KhD2jV+hDewcn3AYj7tBkdPTuaEW\njac9qN0vsiAFnhNvVduegWZ54qpVo1WwxrNoQEFObnFSPImJRGUBXT+BSfg4\n0DAwPg7+tVcPZNv6hfaC95iJ7ugcoijX2OPEWWxBdwOWI2TGwjkeZegDEVHR\nee35+/lurvEMIuaHJgJWQML/D/Ro0m6EbFVPyxeYPRizy+J15+wP2kijpiej\np6LriKVZUTuAqd2QopORHIHxP3Ijf/AjydxpVp+2oOfEMsebgx/3jjFlrL4r\npU+lShk2h94OkKj84Up2OZ10lH/QGWv+++IQJeCx1/Aj1WomsrHkG+MpR5d7\nCOMDujoelodtiiHzQEl/Vyb0jPcKH2CId21hwn2CRlW46nv5pFe17Fq56pcU\nLJMKhVFW8HZiuPEuSRh89MnO5DJpIxircUNxKAFaWtKUmNpEoCb2qiF4Cue/\nOnXFmbbv31ktaHCkrow0gpDelehi3N9hL92/zkYK5gIUYbdZ9WBckVYcj+Ym\ntWq17Ir4huPqXgE5JIdPudu+Tdyf1GMAU80Q610jwxWymJ38GsIoTlbTaYuW\nEjf7\r\n=RsF/\r\n-----END PGP SIGNATURE-----\r\n"},"main":"./src/index.js","_from":".","_shasum":"67eb96c45719766d9d8881b3f219cc4203906a63","gitHead":"5416d577afb01b23e6231a8254ee7dc9e6794920","scripts":{"lint":"eslint src test","test":"mocha --recursive test","format":"prettier -l '{src,test}/**/{deploymentizer,*.js}'","test-unit":"mocha --recursive test/unit","test-functional":"mocha --recursive test/functional"},"_npmUser":{"name":"devops-team","email":"devops@invisionapp.com"},"repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"_npmVersion":"3.10.10","description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","directories":{},"_nodeVersion":"5.5.0","dependencies":{"lodash":"4.17.5","log4js":"0.6.33","js-yaml":"3.5.2","mockery":"2.0.0","bluebird":"3.2.2","fs-extra":"0.30.0","mustache":"2.2.1","commander":"2.9.0","glob-promise":"1.0.6","request-promise":"3.0.0"},"_hasShrinkwrap":false,"devDependencies":{"chai":"3.5.0","nock":"9.0.2","mocha":"2.4.5","sinon":"1.17.6","eslint":"4.9.0","mockery":"2.1.0","prettier":"1.7.4","chai-as-promised":"7.1.1","eslint-config-prettier":"2.6.0","eslint-plugin-prettier":"2.3.1"},"_npmOperationalInternal":{"tmp":"tmp/kit-deploymentizer_4.6.38_1574267025972_0.43345861273398434","host":"s3://npm-registry-packages"}}},"time":{"created":"2016-06-09T15:16:19.277Z","modified":"2025-01-02T17:20:31.983Z","2.0.0":"2016-06-09T15:16:19.277Z","2.1.0":"2016-06-09T15:17:59.882Z","2.1.1":"2016-06-09T15:22:49.598Z","2.1.2":"2016-06-09T15:28:23.694Z","2.1.3":"2016-06-09T20:33:47.576Z","2.1.4":"2016-06-27T17:57:38.356Z","2.1.6-PRERELEASE-v2.0":"2016-07-25T17:30:15.547Z","2.1.7-PRERELEASE-v2.0":"2016-07-25T18:58:37.339Z","2.1.8-PRERELEASE-v2.0":"2016-07-25T21:29:54.460Z","2.1.9-PRERELEASE-v2.0":"2016-07-25T22:12:49.892Z","2.1.10-PRERELEASE-v2.0":"2016-08-17T18:14:50.745Z","2.1.5":"2016-08-19T16:56:35.452Z","2.1.6":"2016-08-23T20:13:29.842Z","2.1.7":"2016-08-24T16:21:38.285Z","2.1.8":"2016-08-25T13:54:36.585Z","2.1.9":"2016-08-26T15:50:44.167Z","2.1.10":"2016-09-08T23:07:43.400Z","2.1.11":"2016-09-13T20:58:08.199Z","2.1.12":"2016-09-13T22:02:18.307Z","2.2.0":"2016-09-15T22:28:32.947Z","2.3.0":"2016-09-16T16:13:01.144Z","2.3.1":"2016-09-21T21:59:24.364Z","2.3.2":"2016-09-21T22:45:49.504Z","2.4.0":"2016-10-20T16:33:27.566Z","2.4.1":"2016-10-21T19:28:44.472Z","2.5.0":"2016-10-21T19:57:36.287Z","2.6.0":"2016-12-08T23:57:48.331Z","2.7.0":"2016-12-11T22:12:12.402Z","2.7.1":"2016-12-12T18:18:44.384Z","3.0.0":"2017-01-25T19:32:53.525Z","3.1.0":"2017-01-26T17:12:53.837Z","3.1.1":"2017-01-26T22:24:01.183Z","3.1.2":"2017-03-02T19:51:03.249Z","3.1.3":"2017-04-04T18:19:12.925Z","3.1.4":"2017-04-13T14:10:45.812Z","3.2.0":"2017-04-13T19:16:51.957Z","3.2.1":"2017-05-01T14:28:34.742Z","4.0.0":"2017-05-18T17:07:44.435Z","4.1.0":"2017-06-16T14:20:31.553Z","4.1.1":"2017-06-19T15:49:41.310Z","4.1.2":"2017-07-06T17:33:17.934Z","4.2.0":"2017-07-17T16:44:13.496Z","4.3.0":"2017-07-17T17:24:49.484Z","4.3.1":"2017-07-18T11:47:14.037Z","4.3.2":"2017-08-25T15:31:53.698Z","4.4.0":"2017-08-30T13:59:35.289Z","4.5.0":"2017-08-30T20:57:48.248Z","4.5.1":"2017-09-06T14:48:23.428Z","4.5.2":"2017-09-15T13:19:54.589Z","4.5.3":"2017-09-18T10:10:58.508Z","4.5.4":"2017-09-18T12:04:53.699Z","4.5.5":"2017-09-18T13:23:34.101Z","4.5.6":"2017-09-18T15:48:53.939Z","4.6.0":"2017-10-19T17:20:50.973Z","4.6.1":"2017-10-27T12:55:15.453Z","4.6.2":"2017-11-07T21:49:31.784Z","4.6.3":"2018-02-19T16:39:41.104Z","4.6.4":"2018-02-28T21:24:57.366Z","4.6.5":"2018-03-08T10:14:14.442Z","4.6.6":"2018-03-14T17:57:34.413Z","4.6.7":"2018-03-19T12:16:30.253Z","4.6.8":"2018-03-19T14:21:00.319Z","4.6.9":"2018-03-21T10:21:26.766Z","4.6.10":"2018-03-21T14:06:14.007Z","4.6.11":"2018-04-04T09:22:45.235Z","4.6.12":"2018-04-10T20:05:35.423Z","4.6.13":"2018-04-11T13:20:34.153Z","4.6.14":"2018-04-11T15:23:10.522Z","4.6.16-PRERELEASE-image-sha.0":"2018-04-11T15:45:01.566Z","4.6.17-PRERELEASE-image-sha.0":"2018-04-11T16:35:38.869Z","4.6.18-PRERELEASE-image-sha.0":"2018-04-11T17:18:09.656Z","4.6.19-PRERELEASE-image-sha.0":"2018-04-12T10:40:18.028Z","4.6.20-PRERELEASE-image-sha.0":"2018-04-12T11:41:17.686Z","4.6.21-PRERELEASE-image-sha.0":"2018-04-13T12:09:43.937Z","4.6.22-PRERELEASE-image-sha.0":"2018-04-13T13:32:47.167Z","4.6.23-PRERELEASE-image-sha.0":"2018-04-13T13:51:37.142Z","4.6.24-PRERELEASE-image-sha.0":"2018-04-13T14:28:47.712Z","4.6.25-PRERELEASE-image-sha.0":"2018-04-13T15:33:53.148Z","4.6.26-PRERELEASE-image-sha.0":"2018-04-13T15:34:27.258Z","4.6.27-PRERELEASE-image-sha.0":"2018-04-13T16:06:42.659Z","4.6.15":"2018-04-16T07:56:03.663Z","4.6.28-PRERELEASE-image-sha.0":"2018-04-16T09:20:57.555Z","4.6.29-PRERELEASE-image-sha.0":"2018-04-16T09:21:13.548Z","4.6.30-PRERELEASE-image-sha.0":"2018-04-16T11:12:28.358Z","4.6.31-PRERELEASE-image-sha.0":"2018-04-16T11:42:28.325Z","4.6.32-PRERELEASE-image-sha.0":"2018-04-16T11:44:04.443Z","4.6.16":"2018-04-16T16:23:05.351Z","4.6.33-PRERELEASE-image-sha.0":"2018-04-16T17:10:51.746Z","4.6.17":"2018-04-16T19:10:03.156Z","4.6.34-PRERELEASE-image-sha.0":"2018-04-16T20:03:07.281Z","4.6.18":"2018-04-16T20:04:52.921Z","4.6.35-PRERELEASE-image-sha.0":"2018-04-17T11:04:32.381Z","4.6.19":"2018-04-17T15:38:42.201Z","4.6.21-PRERELEASE-envs-206.0":"2018-05-03T11:51:22.561Z","4.6.22-PRERELEASE-envs-206.0":"2018-05-03T11:55:56.009Z","4.6.23-PRERELEASE-envs-206.0":"2018-05-03T13:34:11.868Z","4.6.24-PRERELEASE-envs-206.0":"2018-05-03T15:33:21.350Z","4.6.25-PRERELEASE-envs-206.0":"2018-05-03T16:24:08.027Z","4.6.26-PRERELEASE-envs-206.0":"2018-05-07T08:37:38.353Z","4.6.27-PRERELEASE-envs-206.0":"2018-05-07T09:00:14.513Z","4.6.28-PRERELEASE-envs-206.0":"2018-05-07T09:23:10.374Z","4.6.29-PRERELEASE-envs-206.0":"2018-05-07T09:59:30.892Z","4.6.30-PRERELEASE-envs-206.0":"2018-05-08T16:33:49.166Z","4.6.20":"2018-05-08T16:36:36.803Z","4.6.21":"2018-06-12T15:48:35.284Z","4.6.22":"2018-06-12T18:50:35.420Z","4.6.23":"2018-08-08T00:42:46.845Z","4.6.24":"2018-08-13T10:37:38.201Z","4.6.25":"2018-08-15T16:45:02.636Z","4.6.26":"2018-08-16T15:57:55.882Z","4.6.28-PRERELEASE-EV-1421-promise-bugfix.0":"2018-09-13T21:14:56.326Z","4.6.29-PRERELEASE-EV-1421-promise-bugfix.0":"2018-09-13T21:23:40.647Z","4.6.30-PRERELEASE-EV-1421-promise-bugfix.0":"2018-09-13T22:11:30.628Z","4.6.31-PRERELEASE-EV-1421-promise-bugfix.0":"2018-09-13T22:35:09.885Z","4.6.27":"2018-09-13T22:52:29.940Z","4.6.28":"2018-10-03T22:52:00.339Z","4.6.30-PRERELEASE-EV-1429-resource-label.0":"2018-10-10T22:34:06.337Z","4.6.29":"2018-10-11T16:34:45.074Z","4.6.30":"2018-10-11T16:40:00.873Z","4.6.31":"2018-10-17T15:42:28.133Z","4.6.33-PRERELEASE-EV-1579-git-ref.0":"2018-10-29T22:17:19.621Z","4.6.34-PRERELEASE-EV-1579-git-ref.0":"2018-10-29T22:19:43.153Z","4.6.32":"2018-10-29T22:41:28.079Z","4.6.34-PRERELEASE-partial-content-err.0":"2018-11-05T18:54:32.806Z","4.6.33":"2018-11-05T21:46:28.227Z","4.6.34":"2018-12-07T21:29:42.520Z","4.6.35":"2019-04-02T14:17:00.764Z","4.6.36":"2019-10-10T17:27:26.110Z","4.6.37":"2019-10-10T17:50:10.093Z","4.6.38":"2019-11-20T16:23:46.112Z"},"bugs":{"url":"https://github.com/InVisionApp/kit-deploymentizer/issues"},"author":{"name":"Chesley Brown","email":"chesley@invisionapp.com"},"license":"proprietary","homepage":"https://github.com/InVisionApp/kit-deploymentizer","repository":{"url":"git://github.com/InVisionApp/kit-deploymentizer.git","type":"git"},"description":"This will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will gen","contributors":[{"name":"Chuck Freitas","email":"chuck@invisionapp.com"}],"maintainers":[{"email":"itaccounts@invisionapp.com","name":"titaninvision"},{"email":"me@chesleybrown.ca","name":"chesleybrown"},{"email":"erutherford@gmail.com","name":"erutherford"}],"readme":"# kit-deploymentizer\n**[DEPRECATED] Thanks for using this package, but we will no longer support it.**\n\n\n![Team](https://img.shields.io/badge/team-container_application_lifecycle-lightgrey.svg)\n![Status](https://img.shields.io/badge/status-live-green.svg)\n[![Slack](https://img.shields.io/badge/slack-%23docker--kubernetes-blue.svg)](https://invisionapp.slack.com/messages/docker-kubernetes/)\n[![Codeship](https://codeship.com/projects/1106f660-adcb-0133-cbe3-167728a5fef7/status?branch=master)](https://codeship.com/projects/132140)\n\nThis will be a docker image that will intelligently build deployment files as to allow reusability of environment variables and other forms of configuration. It will also support aggregating these deployments for multiple clusters. In the end, it will generate a list of clusters and a list of deployment files for each of these clusters.\n\n## How it works\n\nThe `deploymentizer` uses a combination of ``*-cluster.yaml` files for cluster information, `*-var.yaml` files for configuration, and Mustache templates to generate the deployment files for a Kubernetes cluster. The `deploymentizer` also supports external services for retrieving ENV values that are passed to the templates during generation.\n\nDeploymentizer uses base cluster definition files to define the over-all set of services and the configuration variables that will be used to generate the deployment files. Default values can be set here with the ability to override at the cluster type, and specific cluster level. ENV values are loaded from a external service. This service is loaded as an external plugin at runtime and the returned values are injected during template rendering.\n\nEach cluster has its own `cluster.yaml` and _optional_ `configuration-var.yaml` file that is used to override and extend the base cluster definition. The cluster file can be used to set the default branch to use for that cluster as well as the list of services to override or exclude.\n\nThe `type` configuration files can be used to override/set default values based on which type of cluster is being deployed (testing, staging, production). This value is defined in the `cluster.yaml` file.\n\nThe `image` files contain the docker image to use for each service. This is based on which branch the cluster (or individual service) is set to. This value is injected when rendering the template along with the other variables.\n\nWhen the `deploymentizer` is run, it will load the base-* files, the list of images, and the individual type files. Then it will load each cluster file, asynchronously merging in the base cluster definition, then the type configuration. Precedence goes from base -> type -> cluster with cluster overriding other values. Once that is complete it will render each template to a deployment/service file.\n\n### Base Setup\n\nAn example directory layout would look like:\n\n```sh\n./manifests\n  kit.yaml\n  base-cluster.yaml\n  base-var.yaml\n  ./clusters\n    ./[CLUSTER-NAME]\n      ./cluster.yaml\n      ./configuration-var.yaml\n    ./[CLUSTER-NAME]\n    ...\n  ./resources/\n    ./base-svc.yaml # This is the service template that is shared by all services that require a service\n    ./[RESOURCE-NAME]\n      ./[RESOURCE-NAME]-deployment.mustache\n    ./[RESOURCE-NAME]\n    ...\n  ./type\n    ./develop-var.yaml\n    ./production-var.yaml\n    ...\n  ./images/invision\n    ./[IMAGE-RESOURCE-NAME] # This comes from the base-cluster `resources.[RESOURCE].image_tag` field for each service.\n      ./develop.yaml\n      ./master.yaml\n      ./release.yaml\n      ...\n    ./[IMAGE-RESOURCE-NAME]\n    ...\n./generated # This is where the generated file are saved\n  ./[CLUSTER-NAME] # This comes from the `metadata.name` value of the cluster definition.\n```\n\n### Key Files and types\n\nThis section describe the files used by the `deploymentizer` to render the cluster manifest files. These files are expected to exist in the `LOAD` directory passed in at startup.\n\n##### configuration default name: kit.yaml\n\nThis is a small configuration file used to configure paths and the plugin to be used by Deploymentizer. You can specify the file by passing in the `--conf` flag at startup. This is used to set the paths for the various files and configure the plugin used for loading env configuration. Paths can be a combination or relative or absolute paths. If relative, you can supply a `workdir` option from the command line to define the working directory, otherwise assumed to be the `$pwd`.\n\nDefault `kit.yaml` looks like:\n```\nversion: '2'\nbase:\n  path: /manifests\nimages:\n  path: /manifests/images\n  property: image\ntype:\n  path: ./type\ncluster:\n  path: /manifests/clusters\nresources:\n  path: /manifests/resources\noutput:\n  path: /generated\nplugin:\n  path: /src/plugin/env-api\n```\n\n##### base-cluster.yaml\n\nDefines the over all list of resources.\nThese are included by default in all local cluster configuration unless explicitly disabled.\n\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: base\n  branch: develop\nresources:\n  # Secrets\n  docker-quay-secret:\n    file: ./resources/secrets/docker-quay-secret.yaml\n\n  # Application Resources\n  auth:\n    file: ./resources/auth/auth-deployment.mustache\n    svc:\n      name: auth-svc\n      labels:\n        - name: \"app\"\n          value: \"invisionapp\"\n        - name: \"tier\"\n          value: \"frontend\"\n        - name: \"role\"\n          value: \"service\"\n    containers:\n      auth-con:\n        image_tag: node-auth\n\n  activity:\n    file: ./resources/activity/activity-deployment.mustache\n    image_tag: node-activity\n    svc:\n    ...\n```\n\nThe `kind: ClusterNamespace` is used to determine what type of file this is (vs a `kind: ResourceConfig` for configuration). This file should list all deployable application resources. Each resource should contain at minimum a file, image_tag. If the resource requires a service, the values for that should be configured here also.\n* file defines the path to the resources musache template or yaml file if the file does not use a template.\n* image_tag indicates the name of the image directory that contains the `image` container values. NOTE: these are different than the Application Resource names.\n* svc (Optionally) configuration for a Service. If not present, no service will be generated.\n\n##### base-var.yaml\n\nDefines default configuration information for our kubernetes deployments.\n\nExample base-var.yaml might look like:\n\n```\nkind: ResourceConfig\n# Deployment specific defaults\ndeployment:\n  replicaCount: 3\n  imagePullPolicy: IfNotPresent\n  livenessProbe:\n    path: /healthcheck\n    port: 80\n    initialDelaySeconds: 30\n    timeoutSeconds: 3\n  containerPort: 80\n  rollingUpdate:\n    maxUnavailable: 1\n    maxSurge: 1\nimagePullSecrets:\n  - secret: docker-quay-secret\n  - secret: docker-registry-secret\n\n```\nAll values in this file are converted into data that is passed to the template rendering engine. All of these values can be overridden at the `type` or `cluster` level.\n\n* `kind: ResourceConfig` indicates a resource configuration file (vs a cluster file).\n\n\n##### `type/*-var.yaml`\n\nThis is used to override values for a cluster of a given type. For example you can set the image pull policy and replicaCount for all develop clusters.\n\nAn example *type* file:\n```\n# Cluster Type specific Configuration.\n#\nkind: ResourceConfig\nmetadata:\n  type: develop\ndeployment:\n  replicaCount: 5\n  imagePullPolicy: Always\n```\n\n##### `*-cluster.yaml` files\nCluster specific files are used to override any values needed for a specific cluster. At the minimum it should contain the `kind`, and `metadata.(name, branch, type)` fields. This lets you override specific Resources, setting branch, disabling or adding specific ENV values.\n\nSupported `metadata`\n```\nmetadata:\n  name: [Name of Cluster - required]\n  branch: [Branch used for deployment of cluster, can be overridden at the resource level]\n  type: [ type of cluster, used to import type specific deployment information, and can be used to limit which clusters are generated]\n  disable: [ set to true to have deploymentizer skip processing of this cluster ]\n```\nAn example file would look like:\n\n```\nkind: ClusterNamespace\nmetadata:\n  name: example-1\n  branch: master\n  type: develop\nresources:\n  # auth\n  auth:\n    containers:\n      auth-con:\n        branch: develop\n        env:\n          - name: [ENV_NAME]\n            value: [ENV_VALUE]\n          - name: [ENV_NAME]\n            external: true\n            encoding: base64\n\n  activity:\n    disable: false\n```\nYou can override individual resource values here, including which branch a resource should be deployed from, deployment specific values, and ENVs that are only for this `cluster.resource`. ENVs can be both externally defined (at build time) or predefinded here.\n\n*External ENVs* are environment variables that are only available at build time. This allows the `deploymentizer` to generate a manifest using env values that may be too sensitive to commit to SourceControl. For example create a kubernetes secret from a template with the values injected at build time.\n\nThe name of the external ENV must match the defined name in the `resource.[RESOURCE-NAME].env.name` definition.\n\n##### Disable a Service\nBy default any resource defined in a cluster is considered enabled. You can explicitly change this by setting the value `disable: true`.  \nFor example, in order to disable a service for a specific cluster, add the `resources.[RESOURCE-NAME].disable: true`. This will keep the `deploymentizer` from generating a deployment/service file for that specific resource.\nIf managing lots of clusters, it can be helpful to define your resource in the base cluster file, but configure it as `disable: true` initially. Then only enable it for clusters your want that service deployed on.\nThe other option is to configure it in the base cluster as `disable: false` and enabled it specifically for each cluster.\n\n##### Adding a Service\nYou can add a service just for the cluster by defining the values here. This would allow you to test a service only on a specific cluster before rolling it out to all clusters. The required fields would be:\n\n```\nresources:\n  ...\n  [RESOURCE-NAME]:\n    file: [PATH-TO-MUSTACHE-TEMPLATE]\n    svc:\n      name: [SERVICE-NAME]\n      labels:\n        - name: [KEYS]\n          value: [VALUES]\n```\n\nThe cluster specific configuration file is optional. If defined it would override the configuration defined by the Base/Type files. An example would be:\n\n```\n# Cluster specific Configuration\n#\nkind: ResourceConfig\n```\n### Templates\n\nCurrent implementation uses the Mustache template engine to render the templates. Documentation for Mustache can be found at [http://mustache.github.io/](http://mustache.github.io/).\n\nFor an example the base-svc.mustache file looks like:\n\n```\napiVersion: v1\nkind: Service\nmetadata:\n  name: {{{svc.name}}}\n  labels:\n  {{#svc.labels}}\n    {{{name}}}: {{{value}}}\n  {{/svc.labels}}\nspec: {{{! If Ports are not defined, default to below }}}\n  {{svc.ports}}\n  {{^svc.ports}}\n  ports:\n    - name: web\n      port: 80\n      protocol: TCP\n    - name: web-ssl\n      port: 443\n      protocol: TCP\n  {{/svc.ports}}\n  selector:\n    name: {{{name}}}-pod\n  {{svc.clusterIP}}\n\n```\n\n\n#### Mapping configuration in template\nThis is an example of the values passed to the mustache template engine to render. This example is from the test data located in the `/test/fixtures` directory.\n``` json\n{\n    \"kind\": \"ResourceConfig\",\n    \"metadata\": {\n        \"type\": \"test\"\n    },\n    \"deployment\": {\n        \"replicaCount\": 2,\n        \"imagePullPolicy\": \"IfNotPresent\",\n        \"livenessProbe\": {\n            \"path\": \"/healthcheck\",\n            \"port\": 80,\n            \"initialDelaySeconds\": 30,\n            \"timeoutSeconds\": 3\n        },\n        \"containerPort\": 80,\n        \"rollingUpdate\": {\n            \"maxUnavailable\": 1,\n            \"maxSurge\": 1\n        }\n    },\n    \"imagePullSecrets\": [\n        {\n            \"secret\": \"docker-quay-secret\"\n        },\n        {\n            \"secret\": \"docker-registry-secret\"\n        }\n    ],\n    \"env\": null,\n    \"branch\": \"develop\",\n    \"name\": \"auth\",\n    \"auth-con\": {\n        \"image_tag\": \"invision/node-auth\",\n        \"name\": \"auth\",\n        \"annotations\": {\n            \"kit-deploymentizer/env-api-service\": \"node-auth\"\n        },\n        \"env\": [\n            {\n                \"name\": \"test\",\n                \"value\": \"testvalue\"\n            },\n            {\n                \"name\": \"ENV_ONE\",\n                \"value\": \"value one\"\n            },\n            {\n                \"name\": \"ENV_TWO\",\n                \"value\": \"value two\"\n            },\n            {\n                \"name\": \"ENV_THREE\",\n                \"value\": \"value three\"\n            }\n        ],\n        \"branch\": \"master\",\n        \"deployment\": {\n            \"replicaCount\": 10\n        },\n        \"image\": \"quay.io/invision/node-auth:master-42e7122a0718e25b\"\n    },\n    \"svc\": {\n        \"name\": \"auth-svc\",\n        \"labels\": [\n            {\n                \"name\": \"app\",\n                \"value\": \"invisionapp\"\n            }\n        ]\n    }\n}\n```\n\n#### Plugin For ENV configuration\nThe plugin module should export a class that will be instantiated passing in any parameters defined in the\nkit configuration file loaded by the deploymentizer to the objects constructor.\n\nThe class must contain a function named `fetch`, accepting the parameters `( service, cluster )`.\nService is the resource container object, and cluster is the cluster name as defined by the `ClusterNamespace.metadata.name`.\n\nExample usage:\n```\nconst envConfig = new EnvConfig(options);\nenvConfig.fetch( serviceName, cluster );\n```\nThe `fetch` function must return a Promise. Promises will be converted to bluebird promise via `Promise.resolve(envService.fetch( serviceName, environment, cluster ))`\n\nAny configuration values needed by the plugin should be supplied via the configuration file loaded by the deploymentizer at startup. This should also include the path the plugin to load. Example configuration file for the plugin:\n```\nplugin:\n  path: ./src/plugin/file-config\n  options:\n    configPath: \"/test/fixture/config\"\n```\n\nCalling this with any invalid values (ie wrong service, cluster) should return a error and will stop processing.\n\nThis will be required at system startup and executed _asynchronously_ for every Resource listed in the cluster definition.\n\nAny values returned from the Plugin are merged into the configuration before the template is rendered.\n\n#### Support for Secrets\n\nThe `deploymentizer` will need to support generating a kubernetes secret file in a secure fashion. The `deploymentizer` supports reading ENVs at build time. These ENV's will be injected into the configuration that will be passed into the template engine for the resources template.\n\nNote: Kubernetes Secret values will need to be base64 encoded before being passed to the template for generation.\n\n#### Support for Service only\n\nYou can create a service without an associated `deployment` resource. Include the .svc at the resource level and do not include a resource.file value.\n\n#### Limiting Cluster generation\n\nIf you have a large number of clusters you can limit the clusters that generated to save time and resources. There are 2 options for doing this, one is to set the type of cluster you want generated. Deploymentizer excepts `clusterType` as an option, and if present will only generate clusters that have the matching `metadata.type` tag. The other option is to mark specific clusters as disabled, using the `metadata.disable: true` field.\n\n\n## Running\n\nAs long as you have access to our private docker registry, you can use the image as follows:\n\n1. `docker run --rm quay.io/invision/kit-deploymentizer --help`\n\nThis will show you the help information for the deploymentizer command. If you would like to pass in some files to be parsed and have the generated output saved, you can use volumes. The syntax for this would be:\n\n1. `docker run --rm -v <ABSOLUTE_PATH_FOR_GENERATED_FILES>:/generated -v <ABSOLUTE_PATH_TO_CLUSTER_FILES>:/manifests kit-deploymentizer --save true`\n\n## Using as npm module\n\nAdd `kit-deploymentizer` to your `package.json` and require it like so:\n\n```js\nvar Deploymentizer = require(\"kit-deploymentizer\").Deploymentizer;\n\nvar deploymentizer = new Deploymentizer({\n\tsave: true,\n\toutput: \"/output\",\n  load: \"/manifests\"\n});\n\ndeploymentizer\n\t.process()\n\t.then(console.log)\n\t.catch(console.error)\n\t.done();\n```\n\n## Using as CLI\n\nYou can run the `./src/deploymentizer --help` to see how it works.\n\nNote this method requires node and was tested on version `5.5.0`.\n\n## Expected environment variables\nThe following environment variables are used by this service.\n\n| Variable | Description | Required | Default |\n| :--- | :--- | :--- | :--- |\n| `CLEAN` | Set if the output directory should be deleted and re-created before generating manifest files | yes | `false` |\n| `SAVE` | Sets if the generated manifest files are saved to the output diretory or not | yes | `true` |\n| `CONF` | Sets the path the config file to load | yes | `/manifests/kit.yaml` |\n| `WORKDIR` | Sets the working directory for reading paths defined in the conf file. Allows absolute paths in conf also. | no | `` |\n| `RESOURCE` | Defines specific resource to generate. If not set, generates all resources. | no | `` |\n| `CLUSTER_TYPE` | Defines the cluster type to process (testing, production, etc). If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `CLUSTER_NAME` | Defines the cluster name to process. If not defined processes all clusters found. You cannot define both CLUSTER_TYPE and CLUSTER_NAME at the same time.  | no | `` |\n| `DEBUG` | Log debug events | no | `false` |\n\n## Contributing\n\nSee the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.\n\n## Todo\n\n- [ ] Allow setting the output file name, not the template name. Allow reuse of individual templates (selectsync/mongoreplica examples)\n- [ ] Remove dependency on `base` files and allow defining and importing of groups of resources instead\n- [ ] Rethink `types`, is this still needed\n- [ ] Change `image` handling - this should be more dynamic with services defining which branch/tag to use\n- [ ] Allow setting the `svc` template to render\n- [ ] Add validation of `yaml` files\n- [ ] Allow `kit.yaml` to specify file names\n- [x] Allow plugin to define disabled for service\n- [x] Use event-handler for logging\n- [x] Remove all sync hotspots\n- [x] fix hardcoded path, using kit.yaml loader\n- [x] Refactor plugin, move parsing of result/new format/support other properties\n","readmeFilename":"README.md"}