User Tools

Site Tools


intwtask

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
intwtask [2018/10/26 17:02]
c0rn3j
intwtask [2018/10/26 18:47]
c0rn3j
Line 90: Line 90:
  
 [Service] [Service]
-ExecStart=/bin/bash -c "/usr/bin/docker system prune -af"+ExecStart=/usr/bin/docker system prune -af
  
 [Install] [Install]
Line 117: Line 117:
     - name: test connection     - name: test connection
       ping:       ping:
-    - nameChange DNS to 8.8.8.8 +    - lineinfile
-      shellif ! grep "DNS1=8.8.8.8" /etc/sysconfig/network-scripts/ifcfg-eth0 > /dev/null; then echo "DNS1=8.8.8.8" >> /etc/sysconfig/network-scripts/ifcfg-eth0; chattr +/etc/sysconfig/network-scripts/ifcfg-eth0; fi   +        path: /etc/sysconfig/network-scripts/ifcfg-eth0 
 +        regexp: '^DNS1=' 
 +        line: 'DNS1=8.8.8.8
 +        attr: i
     - name: Add docker-ce repositories     - name: Add docker-ce repositories
-      shellyum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo+      get_url: 
 +        url: https://download.docker.com/linux/centos/docker-ce.repo 
 +        dest: /etc/yum.repos.d/docker-ce.repo
     - name: install docker-ce and its prereqs     - name: install docker-ce and its prereqs
       action: >       action: >
Line 150: Line 155:
         enabled: yes         enabled: yes
         state: started         state: started
 +
                  
 </code> </code>
Line 155: Line 161:
   What is the purpose of  "docker system prune -af" systemd timer in this context and do you think this is needed? Why?   What is the purpose of  "docker system prune -af" systemd timer in this context and do you think this is needed? Why?
 To always get the latest images(though I imagine there's a docker command for this that'd be a better solution for that). To always get the latest images(though I imagine there's a docker command for this that'd be a better solution for that).
 +
 It can also help if the images are somehow broken (crash or hard reboot damaged some files) by simply redownloading them periodically. It can also help if the images are somehow broken (crash or hard reboot damaged some files) by simply redownloading them periodically.
 +
 Though in this context it would fit to cleanup test dev images daily. Though in this context it would fit to cleanup test dev images daily.
  
   What is the difference, if any, of using systemd timer versus cron?   What is the difference, if any, of using systemd timer versus cron?
 Harder to debug and test cron jobs vs systemd units, it's not possible to just 'systemctl start test.service' a cron job, you need to temporarily rewrite the execution to '* * * * *' or similar, and that's just not elegant or convenient. Harder to debug and test cron jobs vs systemd units, it's not possible to just 'systemctl start test.service' a cron job, you need to temporarily rewrite the execution to '* * * * *' or similar, and that's just not elegant or convenient.
 +
 Cron has simplicity going for it though as you can't just create a script that launches on a timer in one line with systemd units. Cron has simplicity going for it though as you can't just create a script that launches on a timer in one line with systemd units.
  
Line 169: Line 178:
  
 Ansible could work with private IPv4 addresses instead of public ones since it's on LAN. I just used the public IPv4 for simplicity. Ansible could work with private IPv4 addresses instead of public ones since it's on LAN. I just used the public IPv4 for simplicity.
-The Ansible playbook could be rewritten so there's no "shell:" commands.+
 Secondary DNS could be 1.1.1.1. DNS is set by making a config file immutable to work around a bug in cloud-init: https://bugs.launchpad.net/cloud-init/+bug/1712680 Secondary DNS could be 1.1.1.1. DNS is set by making a config file immutable to work around a bug in cloud-init: https://bugs.launchpad.net/cloud-init/+bug/1712680
 +
 The Ansible playbook seems okay, but as I first manually installed everything before turning it into a playbook, I don't have a clean-state server to verify. The Ansible playbook seems okay, but as I first manually installed everything before turning it into a playbook, I don't have a clean-state server to verify.
  
intwtask.txt · Last modified: 2018/10/26 19:46 by c0rn3j