Update usage of instance in scaling documentation (#7536)

Co-authored-by: Kris Stern <[email protected]>

content/doc/book/scaling/architecting-for-manageability.adoc

@@ -23,11 +23,11 @@ requires a newer version of the Jenkins core, there is no automatic way to
 detect conflicts between plugins or to automatically quantify the impact of
 upgrading a plugin.
 
-Jenkins administrators test plugin and core version updates before performing them on the production instance.
-This kind of testing requires a copy or "test instance" of the production server to act as the sandbox for such tests.
+Jenkins administrators test plugin and core version updates before performing them on the production controller.
+This kind of testing requires a copy or "test deployment" of the production server to act as the sandbox for such tests.
 Effective upgrade testing can prevent production downtime.
 
-== Test Instances
+== Test Controllers
 
 A test controller is a Jenkins controller used solely for testing configurations and
 plugins in a non-production environment.
@@ -42,13 +42,13 @@ Test controllers should have identical configurations, jobs, and plugins as the
 production controller so that test upgrades  will most closely resemble the
 outcomes of a similar change on your production controller. For example, installing
 the Folders plugin while running a version of the Jenkins core older than
-1.554.1 will cause the instance crash and be inaccessible until the plugin is
+1.554.1 will cause the controller crash and be inaccessible until the plugin is
 manually uninstalled from the _plugin_ folder.
 
-[[setting-up-a-test-instance]]
-=== Configuring a test instance
+[[setting-up-a-test-controller]]
+=== Configuring a test controller
 
-There are many methods for setting up a test instance, but the commonality
+There are many methods for setting up a test controller, but the commonality
 between them all is that the _$JENKINS_HOME_ between them is nearly identical.
 Whether this means that most all of the  _$JENKINS_HOME_
 folders are version controlled in a service like GitHub and mounted manually or
@@ -134,9 +134,9 @@ git commit -m "first commit"
 git push
 ----
 
-Now you can install Jenkins to a fresh instance and "git clone" this
-_$JENKINS_HOME_ from the git repository to your new instance. You will need to
-replace the files in the new instance with your version-controlled files to
+Now you can install Jenkins to a fresh deployment and "git clone" this
+_$JENKINS_HOME_ from the git repository to your new controller. You will need to
+replace the files in the new controller with your version-controlled files to
 complete the migration, whether through scripts or through a drag-and-drop
 process.
 
@@ -150,7 +150,7 @@ When it comes to version controlling your $JENKINS_HOME, just follow the
 instructions in the previous section.
 
 The next step will be to create a Docker image with identical configurations to
-your production instance's - operating system (Linux-only), installed
+your production deployment's - operating system (Linux-only), installed
 libraries/tools, and open ports. This can be accomplished through Dockerfiles.
 
 You will then just need to create mounted storage on your Docker server with a
@@ -243,7 +243,7 @@ docker run -d \
 .Test agents
 
 Test controllers can be connected to test agents, but this will require further
-configurations. Depending on your implementation of a test instance, you will
+configurations. Depending on your implementation of a test controller, you will
 either need to create a Jenkins Docker agent image or an agent VM. Of course,
 open-source plugins like the EC2 plugin also the option of spinning up new
 agents on-demand.
@@ -279,7 +279,7 @@ components are behaving abnormally and which resources are insufficient. The
 administrator can
 link:https://wiki.jenkins.io/display/JENKINS/Obtaining+a+thread+dump[take thread
 dumps] and heap dumps to get some of this information, but in some cases where
-the instance has become non-operational and taking a thread dump is impossible,
+the controller has become non-operational and taking a thread dump is impossible,
 it is useful to have a persistent record outside of Jenkins itself to reference
 when such troubleshooting is required.
 

content/doc/book/scaling/architecting-for-scale.adoc

@@ -591,7 +591,7 @@ build records are only as important as your organizations deems them.
 
 .System configurations
 
-Your instance's system configurations exist in the root level of the
+Your controller's system configurations exist in the root level of the
 _$JENKINS_HOME_ folder:
 
 [literal]
@@ -611,7 +611,7 @@ back up the _config.xml_.
 
 .Plugins
 
-Your instance's plugin files (.hpi and .jpi) and any of their dependent
+Your deployment's plugin files (.hpi and .jpi) and any of their dependent
 resources (help files, _pom.xml_ files, etc) will exist in the _plugins_ folder
 in $JENKINS_HOME.
 
@@ -652,11 +652,11 @@ _$JENKINS_HOME_ was created. It is also meant to be a flag that the secret.key
 file is a deprecated way of encrypting information.
 
 The files in the secrets folder are used by Jenkins to encrypt and decrypt your
-instance's stored credentials, if any exist. Loss of these files will prevent
+controller's stored credentials, if any exist. Loss of these files will prevent
 recovery of any stored credentials. _hudson.util.Secret_ is used for encrypting
 some Jenkins data like the credentials.xml, while the _master.key_ is used for
 encrypting the hudson.util.Secret key. Finally, the _InstanceIdentity.KEY_ is
-used to identity this instance and for producing digital signatures.
+used to identity this controller and for producing digital signatures.
 
 === Define a Jenkins controller to rollback to
 
@@ -667,7 +667,7 @@ If a high availability set up has not been enabled and no back up of that
 controller's filesystem has been taken, then an corruption of a machine running
 Jenkins means that all historical build data and artifacts, job and system
 configurations, etc. will be lost and the lost configurations will need to be
-recreated on a new instance.
+recreated on a new controller.
 
 1. Backup policy - In addition to creating backups using the previous section's
    backup guide, it is important to establish a policy for selecting which backup
@@ -678,13 +678,13 @@ recreated on a new instance.
 == Resilient Jenkins Architecture
 
 Administrators are constantly adding more and more teams to the software
-factory, making administrators in the business of making their instances
+factory, making administrators in the business of making their controllers
 resilient to failures and scaling them in order to onboard more teams.
 
 Adding build nodes to a Jenkins controller while beefing up the machine that runs
 the Jenkins controller is the typical way to scale Jenkins. Said differently,
 administrators scale their Jenkins controller vertically. However, there is a limit
-to how much an instance can be scaled. These limitations are covered in the
+to how much a controller can be scaled. These limitations are covered in the
 introduction to this chapter.
 
 Ideally, controllers will be set up to automatically recover from failures without
@@ -717,8 +717,8 @@ Add build servers to your controller to ensure you are conducting actual build
 execution off of the controller, which is meant to be an orchestration hub, and
 onto a "dumb" machine with sufficient memory and I/O for a given job or test.
 
-.Step 4: Setup a test instance
+.Step 4: Setup a test controller
 
-A test instance is typically used to test new plugin updates. When a plugin is
+A test controller is typically used to test new plugin updates. When a plugin is
 ready to be used, it should be installed into the main production update
 center.

content/doc/book/scaling/hardware-recommendations.adoc

@@ -55,7 +55,7 @@ more of memory. You will also need to factor in CPU overhead for Jenkins if
 there are a lot of users who will be accessing the Jenkins user interface.
 
 It is generally a bad practice to allocate executors on a controller, as builds can
-quickly overload a controller's CPU/memory/etc and crash the instance, causing
+quickly overload a controller's CPU/memory/etc and crash the controller, causing
 unnecessary downtime. Instead, it is advisable to set up agents that the Jenkins
 controller can delegate jobs to, keeping the bulk of the work off of the
 controller itself.

content/doc/book/scaling/index.adoc

@@ -19,7 +19,7 @@ concurrent jobs, job results and logs, and even large numbers of Jenkins control
 The audience for this chapter is expert Jenkins users, administrators, and those
 planning large-scale installations.
 
-If you are a Jenkins administrator and want to know more about managing Jenkins nodes and instances, see
+If you are a Jenkins administrator and want to know more about managing Jenkins nodes and controllers, see
 <<managing#,Managing Jenkins>>.
 
 For an overview of content in the Jenkins User Handbook, see

content/doc/book/scaling/scaling-jenkins-on-kubernetes.adoc

@@ -29,7 +29,7 @@ called Jenkins agents.
 Scalability is a measure that shows the ability of a system to expand its capabilities
 to handle additional load.
 One of the strongest sides of Jenkins is that it has a scaling feature out-of-the-box.
-Jenkins scaling is based on the controller/agents model, where you have a number of agent instances and one main Jenkins controller that is responsible mainly for distributing jobs across the agents.
+Jenkins scaling is based on the controller/agents model, where you have a number of agents and one main Jenkins controller that is responsible mainly for distributing jobs across the agents.
 Jenkins agents run a small program that communicates with the Jenkins controller to check if there’s any job it can run.
 When Jenkins finds a job scheduled, it transfers the build to the agent.
 
@@ -146,7 +146,7 @@ minikube ip
 192.168.99.100
 ----
 
-Now we can access the Jenkins controller instance at \http://192.168.99.100:32664/
+Now we can access the Jenkins controller at \http://192.168.99.100:32664/
 
 == Jenkins Agents Configuration