Unless you are using this workshop as part of a specific remix, your event marketing should ensure your audience is aligned with Who Will Enjoy This Workshop?
Per Classroom Delivery
If the AWS account is owned by someone other than GitLab or AWS, then it may make sense for the classroom resources to remain running after the class for participant exercise completion, doing bonus exercises and/or experimentation.
If this is done, it makes sense to use the instructions in EKS Stop, Start & Scheduling to only have the EKS nodes, Bastion host and runners available during business hours - or even limited business hours (e.g. M-F 12noon-5pm) across the timezones where participants normally reside.
The Tuning and Troubleshooting Guide has a special section for “Classrooms” which includes helpful tips for scaling compute resources for the classroom.
How to Report Problems after Troubleshooting
Instructor Led Non-Infrastruture - allows the shared GitLab and AWS resources to be prestaged and then allow participants to focus on using GitLab to build applications for AWS EKS. Also does not require that participants have AWS accounts, nor Kubernetes cluster access.
Instructor Led with Infrastructure - participants can use per-student AWS accounts and per-student EKS Clusters to learn how to setup these components - the runtime of this format is several hours longer. Per-student AWS accounts will ensure no resources conflict and participants do not need to make too many region oriented modifications to the exercises and out of the box cloud formation templates.
Self-Paced - participants need to perform all infrastructure setup, unless they have a team that can preset the instructor prep portions for them.
Instructors may be tempted to have everyone setup their own cluster in their own AWS account or setup their own GitLab Server - you should be certain that your workshop audience really needs to do these infrastructure provisioning activities in their production jobs before making them part of the workshop. It is a classic antipattern to lose your audience by putting them through hours of prep work before they get to the meat of what they want to learn for their day job.
If a given run of the workshop is actually for a team who needs to perform cluster and GitLab setup - then participants can simply complete all Instructor-Led sections. It is best to isolate with an AWS account per-participant in this use case.
If you are running in a free license or unlicensed GitLab Instance or gitlab.com group, you will not have the feature “Group Access Tokens” available to you. In that case you will need to create a Personal Access Token instead of a Group Access Token. Others in the same classroom will be able to see each other’s PAT. If you are using a production GitLab user account, this exposes access to all the repositories each personal id has access to the class during the time your PAT is configured. Ways to minimize this risk include:
If using a paid GitLab license, use Group Access Tokens - which is documented in the lab.
Use a non-production user account (create one for the class - easy on .com, may not be easy if your organization uses GitLab SSO or LDAP with another Identity provider).
Use a non-production GitLab Instance.
Do not give participants GitLab access to the classgroup, but instead only to their personal group.
Remove the PAT as soon as the class is done (still exposed during the class).
The Lab “Setup the GitOps Pull Agent” requires entries for student projects in a file in the classroom group level “Cluster Management” project. This approach is much simpler than each student gaining cluster access to install their own agent.
Please read the “Check With Instructor” note in that lab to assess and select an approach that will work within the timeframe and teaching objectives you are operating under.
Since we have the GitLab Agent doing both CD Push (and Labs in 3.x show it first) as well as CD Pull, it can be challenging for participants to perceive when the Agent is receiving a Push from a runner and when it is independently pulling using manifests. The exercises do address this by having participants examine the contents of the manifest update jobs and the changed manifests - but to really drive it home you can tail the log of the Kubernetes Agent log as a “running” demo while they complete exercises 4.5 and 4.6.
In 4.5 and this lab you may also want to have a trace of the GitLab Agent displaying while participants are working in order to reinforce that the GitLab Agent is pulling the changes. Otherwise it can seem as though they are being pushed by CI jobs.
To do this, login to the EKS Bastion host the same was as was done in “Prep Lab 2.3: Use GitLab K8s Agent to Integrate The Cluster with GitLab” to install the GitLab Agent. Then run this command kubectl logs -f -l=app=gitlab-agent -n gitlab-agent
For more troubleshooting information visit Troubleshooting the GitLab agent for Kubernetes