2 ms·
In Arion, dependencies between services are still implicit, as at the end of the day what you're doing is generating a docker-compose.yml file. There are other
by pxc 4y ago
In Arion, dependencies between services are still implicit, as at the end of the day what you're doing is generating a docker-compose.yml file.
There are other tools that model things more like the OP is thinking, though! With Disnix, you have an explicit service model where you declare those dependencies.
See: https://hydra.nixos.org/build/203347995/download/2/manual/ https://hydra.nixos.org/build/203347995/download/2/manual/ or maybe Sander's blog posts on it
- Randomdevops 4y agoYes! I haven't quite wrapped my head around Nix yet, but https://hydra.nixos.org/build/203347995/download/2/manual/#ex-services-model https://hydra.nixos.org/build/203347995/download/2/manual/#e... ### Databases zipcodes = { name = "zipcodes"; pkg = customPkgs.zipcodes; dependsOn = {}; type = "mysql-database"; }; ... ### Web services ZipcodeService = { name = "ZipcodeService"; pkg = customPkgs.ZipcodeService; dependsOn = { inherit zipcodes; }; type = "tomcat-webapplication"; }; ... And then in the ZipcodeService you can access your dependency attributes https://hydra.nixos.org/build/203347995/download/2/manual/#ex-zipcode-service https://hydra.nixos.org/build/203347995/download/2/manual/#e... contextXML = '' <Context> <Resource name="jdbc/ZipcodeDB" auth="Container" type="javax.sql.DataSource" maxActivate="100" maxIdle="30" maxWait="10000" username="${zipcodes.target.container.mysqlUsername}" password="${zipcodes.target.container.mysqlPassword}" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://${zipcodes.target.properties.hostname}:${toString (zipcodes.target.container.mysqlPort)}/${zipcodes.name}?autoReconnect=true" /> </Context> 3 ''; Still wondering if the 'zipcodes.target.properties.hostname' is a fixed schema that could be validated or if it is just a map... So yeah it looks like I'm searching for what they describe as a 'services-model' where as docker compose is what they describe as a 'deployment model'... Their idea of always doing a new deployment and leaving the old versions running, so you can always do a rollback is interesting.