Page History

...

How to test service is accessible to other build containers

1. TODO: Apparently the artifact needs to be Other containers not in the same namespace as the build containers if they want to access it, so in that case, may just put the build containers in the artifact namespace? Or put the artifact api in the namespace of the build containers

IMPORTANT

Jerry vacation 7-11 to 7-16

S3DF down 7-10 to 7-12 including the cluster

So come up with what work your going to do in those days since clusters are down

1. documentation, diagrams, planning?
2. mps prep?
3. Look into ansible (alternative for some systems that can't use containers yet. Also can configure more than the app/packages, can also configure networking, DNS, monitoring). Then once done, maybe help out Lukas with the python conversions, at least until s3df is back up

Ansible Notes (TODO: Move to a different page once done)

1. can still access the service with <service-name>.<namespace>. 
   1. example: where artifact is the namespace 

   2. curl -X 'GET' http://artifact-api-service.artifact:8080/component

2. Introduction information
   1. Ansible is an orchestration/automation tool, just like Chef or Pupper which are other alternatives to ansible, but ansible main advantage is that it can work through ssh, so target machines don't need ansible installed.
   2. ansible solves the problem of performing 'day-1' operations of infrastructure (installing os, dependency packages, network configurations, etc) source:DevOps: Difference between Ansible and orchestrators like Kubernetes - Stack Overflow
   3. Big advantage is that it uses declarative playbooks (define what you want done) instead of imperative scripting (define what you want and how). 
   4. day-0; get all of your infrastructure; hardware/public-cloud etc. day-1; use something like Ansible to setup the infrastructure components (EC2 nodes, hardware servers or GCE instances) day-2; install k8s on them to start running containerized workloads day-3; use k8s native mechanisms to deploy and manage and monitor applications
(Day 2 and 3 is ideal, but i think we will just deploy the containers through our build system not k8s)
   5. Ansible can help with availability, and we will use it to test, like if an ioc needs another ioc to run for testing, specifying which machine and what resources, ansible should handle that deployment.
3. Why Ansible
   1. Reduces complexity and runs anywhere.
   2. Lets you automate any task,
   3. Agentless, the managed nodes only need to be accessible via ssh and sftp or scp, and python installed.
4. How it works Ansible Tutorial for Beginners: Playbook & Examples (spacelift.io)
   1. A control node (machine with ansible installed) sends commands/instructions to managed nodes/machines.
   2. Ansible structure: 
      1. Units of code that the control node executes on the managed nodes are modules
      2. Each module is invoked by a task
      3. An ordered list of tasks form a playbook
      4. The managed nodes are represented in a simplistic inventory file
   3. The user defines the playbooks using YAML