aknuds1's questions

No CoreOS 899.15.0, como faço para atualizar um arquivo de unidade enviado anteriormente via Fleetctl?

Enviei anteriormente o arquivo de unidade [email protected], mas quero atualizá-lo para uma versão revisada:

$ fleetctl list-unit-files
UNIT                HASH    DSTATE      STATE       TARGET
[email protected]    76b05ae inactive    inactive    -
[email protected]              faa7a16 inactive    inactive    - 

Quando tento reenviar [email protected], o Fleetctl apenas me avisa que as versões local e de registro são diferentes:

$ fleetctl submit rethinkdb\@.service
WARNING: Unit [email protected] in registry differs from local unit file [email protected]

Estou definindo um serviço one-shot em minha configuração de nuvem do CoreOS, mas está falhando devido à impossibilidade de baixar arquivos do Google Cloud Storage (via wget):

13 de abril 11:09:56 staging-node-ys9y.c.experimentalberlin.internal sh[1132]: conectando-se a storage.googleapis.com|74.125.133.128|:443... falhou: conexão expirou.

Como devo garantir que o serviço seja capaz de baixar arquivos da Internet?

Minha configuração de nuvem

#cloud-config
coreos:
  units:
    - name: bootstrap.service
      command: start
      content: |
        [Unit]
        Description=Bootstrap instance
        After=network-online.target
        Requires=network-online.target

        [Service]
        Type=oneshot
        RemainAfterExit=true
        ExecStart=/usr/bin/mkdir -p /tmp/kubernetes-staging
        ExecStart=cd /tmp/kubernetes-staging
        ExecStart=/bin/sh -c "cd /tmp/kubernetes-staging && wget https://storage.googleapis.com/experimentalberlin/staging.tar.gz && tar xf staging.tar.gz"
        ExecStart=/tmp/kubernetes-staging/worker/bootstrap.sh

        [Install]
        WantedBy=local.target

Estou executando o CoreOS beta 991.1.0 em uma instância do Google Compute Engine, onde o cloud-config é configurado por meio da user_datavariável de metadados. Minha configuração de nuvem se parece com isso:

#cloud-config
write_files:
  - path: "/etc/kubernetes/kube.conf"
    permissions: "0644"
    owner: "root"
    content: |
      apiVersion: v1
      kind: Config
      clusters:
      - name: kube
        cluster:
          server: https://127.0.0.1:443
          certificate-authority: /etc/kubernetes/ssl/ca.pem
      users:
      - name: kubelet
        user:
          client-certificate: /etc/kubernetes/ssl/master-client.pem
          client-key: /etc/kubernetes/ssl/master-client-key.pem
      contexts:
      - context:
          cluster: kube
          user: kubelet
ssh_authorized_keys:
  - "SECRET"
coreos:
  etcd2:
    discovery: https://discovery.etcd.io/106b575a45f2abefdaea40ebba4d0d84
    initial-advertise-peer-urls: https://$private_ipv4:2380
    listen-peer-urls: https://$private_ipv4:2380
    listen-client-urls: https://0.0.0.0:2379
    advertise-client-urls: https://$private_ipv4:2379
  units:
    - name: etcd2.service
      command: start
      drop-ins:
        - name: 30-certificates.conf
          content: |
            [Service]
            # Client Env Vars
            Environment=ETCD_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem
            Environment=ETCD_CERT_FILE=/etc/kubernetes/ssl/master-client.pem
            Environment=ETCD_KEY_FILE=/etc/kubernetes/ssl/master-client-key.pem
            # Peer Env Vars
            Environment=ETCD_PEER_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem
            Environment=ETCD_PEER_CERT_FILE=/etc/kubernetes/ssl/master-peer.pem
            Environment=ETCD_PEER_KEY_FILE=/etc/kubernetes/ssl/master-peer-key.pem
    - name: fleet.service
      command: start
    - name: swap.service
      command: start
      content: |
        [Unit]
        Description=Turn on swap

        [Service]
        Type=oneshot
        Environment="SWAPFILE=/swap"
        RemainAfterExit=true
        ExecStartPre=/usr/sbin/losetup -f $SWAPFILE
        ExecStart=/usr/bin/sh -c "/sbin/swapon $(/usr/sbin/losetup -j $SWAPFILE | /usr/bin/cut -d : -f 1)"
        ExecStop=/usr/bin/sh -c "/sbin/swapoff $(/usr/sbin/losetup -j $SWAPFILE | /usr/bin/cut -d : -f 1)"
        ExecStopPost=/usr/bin/sh -c "/usr/sbin/losetup -d $(/usr/sbin/losetup -j $SWAPFILE | /usr/bin/cut -d : -f 1)"

        [Install]
        WantedBy=local.target

No entanto, embora eu tenha configurado o etcd2 para iniciar na inicialização, isso não acontece. Por que o etcd2 não inicia automaticamente?

Estou sofrendo com o uso excessivo de memória, atualmente totalizando ~ 940 MB físicos e ~ 1 GB de memória de troca, no meu host Ubuntu 15.04 x64 Docker (1.9.1-cs2, build 4ade326). Segundo top, o Docker é responsável pelo consumo de cerca de 780 MB de memória swap. Como posso descobrir por que o Docker está usando tanto swap?

Estou executando principalmente um contêiner Node.js Docker, que não parece consumir muita memória. O uso de memória também aumenta em algumas horas, pois é bastante modesto após a inicialização.