Profile
By j.dickey | Published | No Comments
The profile file, central to UI initialization, manages the fundamental structural initialization of the VMs FPS Aloha structure within a domain. This initialization typically remains unchanged throughout the lifecycle of the family release, as it is structurally placed in a filesystem area under administrative control. The profile only needs modification when adding new Core servers (servers capable of running essential “Make” functions). New core server entries should be added only when an existing core server is retired or when a new domain is introduced. Although FPS Aloha-P1 does not ensure a server is of the Core type, this feature will be implemented during the later patches of the FPS Aloha release
ServiceNow Actions do not load this profile. Since the load is crucial for FPS Aloha initialization, it must be included in the Action itself or as a callable snippet during Action initialization. In previous Foundational Ops releases, the profile and associated callable snippet for ServiceNow Actions loaded public CmdLets through PowerShell’s Module load capability. However, this approach slowed down the overall action duration in ServiceNow and its use was discontinued in the FPS Aloha release. Although not used, the FPS Aloha structure remains in a module-capable format, and module loads can be enabled by uncommenting the section of the profile that checks $Env:PSModulePath within profile.ps1.
To start in the profile with a few base variables need to be constructed for use:
$YYYY ...................... The current 4 digit year
$YY ........................ The current 2 digit year
$MM ........................ The current 2 digit month
$DD ........................ The current 2 digit day
$global:pro_CurrentUser .... The current login userid
$global:pro_CI ............. The current VM/Client device
$global:pro_ModulesUsed .... $true if FPS modules are configured, $false if notDomain initialization occurs using the \FPS\MetaData\Pro-Cis[domain] metadata located in the source path. This is the only time where the source is used during the profile initialization and is the only fully qualified path available to load from at this point in the process. After the domain directed CIs are loaded, we can us this information to determine the attributes for the current CI.
The server farm initialization process has been enhanced from prior releases for supportability and clarity. Previously, several configuration files per domain were used and significant duplication was present, complicating maintenance of the files. In the Aloha release, core servers (servers that manage source code) are configured within the profile file, and secondary CI attribute configurations are loaded from a separate CI files located in the metadata path. Once the server array is configured, values linked to $global:pro_CI are loaded into global variables from the corresponding $global:pro_CIAttributes entry:
$global:pro_CI.CIID – The unique numerical ID given to the CI. Once the profile completes, only this variable or $global:pro_CIBase.CI and $global:pro_CIBase.CITemplate should be used within all other CmdLets or Snippets to reference the VM/Server/Client.
$global:pro_CI.CI – The unique device name given to the physical CI VM or client. Once the profile completes, only this variable or $global:pro_CIBase.CIID and $global:pro_CIBase.CITemplate should be used within all other CmdLets or Snippets to reference the VM/Server/Client.
$global:pro_CI.CITemplate – The unique numerical ID given to the CI. Once the profile completes, only this variable or $global:pro_CIBase.CIID and $global:pro_CIBase.CI should be used within all other CmdLets or Snippets to reference the VM/Server/Client.
$global:pro_CI.RuntimeDrive – The current CI machine FPS runtime drive (typically D:)
$global:pro_CI.Type – The orientation of the CI specific FPS community of CIs. Currently these are “Core”, “Server” and “Solo”. Other variations of Solo can exist, but only one “Core” and one “Server” CI can exist for one region. Use “Server” for the storage facility/MID Server/CICD go-to, “Core” for where the source and any “Make” executions stem from, and “Solo” for all that use FPS in runtime mode.
$global:pro_CI.Domain – The domain where the CI physically exists. Under most cases there will only be one domain where all of the FPS CIs exist, but in enterprise situations many domains can be in play.$global:pro_DefaultDomainis a simple variable containing the default domain that is typically used in multi-domain situations.
$global:pro_CI.SvcAcct – The service account to use when remotely connecting to the FPS instance via the UI.
$global:pro_CI.Family – The family name of the FPS set of code used by the CI.
$global:pro_CI.Patch – The FPS patch level currently used by the CI.
$global:pro_CI.CanConnectToSource – If a Make is required for a remote VM or Server, the FPS Make actions on the Core server for the remote VM or Server will be sent and installed on the device.
$global:pro_CI.SourceDrive – Pre-formatted root for where the source drive exists for the device.
With the current CI fully identified, the next step is to establish the CI’s base locations. To achieve this, the CI’s release level ($global:pro_Release) and default domain ($global:pro_DefaultDomain) are derived from the $global:pro_CI variables to serve as constructor variables. The following base variables are then created for ongoing use:
$global:pro_CIBase.CIID – The current unique numerical ID given to the CI. Reproduced here so that it can be altered for a remote Make if necessary without affecting the pro_CI values.
$global:pro_CIBase.CI – The current CI machine name. Reproduced here so that it can be altered for a remote Make if necessary without affecting the pro_CI values.
$global:pro_CIBase.CITemplate – The current CI template for MID servers, etc. Reproduced here so that it can be altered for a remote Make if necessary without affecting the pro_CI values.
$global:pro_CIBase.RuntimeFamily – The current runtime FPS family. Reproduced here so that it can be altered for a remote Make if necessary without affecting the pro_CI values.
$global:pro_CIBase.RuntimePatch – The current runtime FPS patch level. Reproduced here so that it can be altered for a remote Make if necessary without affecting the pro_CI values.
$global:pro_CIBase.RuntimeRoot – Root path for the FPS runtime location.
$global:pro_CIBase.RuntimeCollections – Root path for the FPS runtime collection’s location.
$global:pro_CIBase.RuntimeContainer – Root path for the FPS runtime containers.
$global:pro_CIBase.RuntimeMedia – Root path for the FPS Media location.
$global:pro_CIBase.RuntimeMetadata – Root path for the FPS Metadata location.
$global:pro_CIBase.RuntimeScratch – Root path for the FPS scratch location.
$global:pro_CIBase.RuntimeLogs – Root path for the FPS log location.
$global:pro_CIBase.RuntimeWeb – Root path for the FPS admin web directory.
After constructing the base level variables, the remaining base locations (Pro-Locations.ps1) are loaded. These locations are then utilized for the subsequent configuration aspects within the Pro-Config.ps1 snippet.
Referenced Source Files
Source for profile.ps1, Pro-Config.ps1, Pro-Locations.ps1 and examples of domain based CI configurations Pro-CIsDMN01.ps1 and Pro-CIsDMN02.ps1.
Leave a Reply
You must be logged in to post a comment.