Pinning a commit hash is definitely 1 step to reproducibility. But another step is that all build inputs and upstream sources must also be content addressed and available. One challenge with this security updates. On 12/09/2016 7:05 PM, "Tobias Pflug" <tobias.pf...@gmx.net> wrote:
> If I may just jump in with a question: What I feel uneasy about is to just > use some channel. Is that what everyone does? I usually pinpoint a specific > commit so that i know that my deployments are actually deterministic about > what nixpkgs set is being used. > > Am I just being paranoid/impractical? Maybe it is even an anti-pattern > since I obviously have to manually update then. > > Thanks in advance for any input :) > > -Tobi > > Sent from my iPhone > > > On 06 Sep 2016, at 15:06, Игорь Пашев <pashev.i...@gmail.com> wrote: > > > > I'm using NixOps in production, EC2, Hetzner, VBox with no issues. > > > > Of course, commit NixOps state (JSON) in git with git-crypt. And this > > wrapper for NixOps: > > > > #!/usr/bin/env bash > > > > set -euo pipefail > > > > NIXPKGS=https://github.com/NixOS/nixpkgs-channels/ > archive/nixos-15.09.tar.gz > > NIXOPS=${NIXOPS:-nixops} > > export NIX_PATH=nixpkgs="$NIXPKGS":. > > > > usage () { > > cat <<USAGE > > Usage: $0 <nixops command> <realm/spec.nix> [nixops options] > > Examples: > > $0 deploy realms/vbox.nix > > $0 info realms/vbox.nix > > $0 deploy realms/dumpoo.nix --build-only > > $0 destroy realms/cats.nix --include slothcat > > USAGE > > } > > > > fatal () { > > echo '** ERROR:' "$@" >&2 > > usage >&2 > > exit 1 > > } > > > > if [ $# -lt 2 ]; then > > fatal "missing agruments." > > fi > > > > CMD="$1"; shift > > REALM_NIX="$1"; shift > > > > case "$REALM_NIX" in > > *realms/*.nix) REALM=$(basename "$REALM_NIX" .nix);; > > *) fatal "invalid realm spec: $REALM_NIX";; > > esac > > > > cd "$(dirname "$0")" > > > > state="secrets/nixops-${REALM}.json" > > db=$(mktemp -u "secrets/tmp.${REALM}.XXXXXX.nixops") > > > > trap 'save' EXIT > > > > save() { > > if [ -f "$db" ]; then > > "$NIXOPS" export -s "${db}" > "${state}.tmp" > > mv "${state}.tmp" "${state}" > > rm -f "$db"* > > fi > > } > > > > create() { > > "$NIXOPS" create -s "$db" -d "$REALM" "<realms/${REALM}.nix>" > > } > > > > case "$CMD" in > > create) > > [ ! -f "$state" ] || fatal "\`$state' already exists." > > create > > ;; > > *) > > [ -f "$state" ] || fatal "\`$state' does not exists." > > "$NIXOPS" import -s "${db}" < "$state" > > "$NIXOPS" "$CMD" -s "$db" -d "$REALM" "$@" > > ;; > > esac > > > > > > > > And makefile for development with vbox; > > > > REALM = cats > > override STATE = secrets/nixops-vbox-$(REALM).json > > > > build: $(STATE) > > ./let deploy realms/vbox-$(REALM).nix --build-only > > > > destroy: > > ./let $@ realms/vbox-$(REALM).nix --confirm > > > > info deploy check send-keys start stop reboot: $(STATE) > > ./let $@ realms/vbox-$(REALM).nix > > > > $(STATE): > > ./let create realms/vbox-$(REALM).nix > > > > 2016-09-05 19:01 GMT+03:00 Aloïs Cochard <alois.coch...@gmail.com>: > >> Hi all, > >> > >> We are experimenting with NixOps and we are having great success. We do > plan > >> to use it for our development infrastructure, and it seems to be very > >> promising. > >> > >> In the light of applying the same technology on our production stack, > I'm > >> curious to know how NixOps is used "for real"? Do you use it in > production? > >> > >> Do you have some success story to share? > >> > >> Would love to know more about how it is used, the size of clusters, ... > >> > >> Thanks in advance! > >> > >> -- > >> Λ\oïs > >> http://twitter.com/aloiscochard > >> http://github.com/aloiscochard > >> > >> _______________________________________________ > >> nix-dev mailing list > >> nix-dev@lists.science.uu.nl > >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > > _______________________________________________ > > nix-dev mailing list > > nix-dev@lists.science.uu.nl > > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev