Foundational Operations PowerShell Architecture
By j.dickey | Published | No Comments
Foundational PowerShell (FPS) Operations leverages insights from prior support lessons learned which were improved upon previous ServiceNow implementations. I’ll be referring to all prior and current releases of the method as “Foundational Operations,” or “Foundational Ops,” or “FPS Ops” throughout the blogs vs using a specific name used for prior implements. If a method has a special use necessary within a target product platform I will refer to the target product for reference purposes only. Since the ServiceNow product requires a few unique design patterns, a ServiceNow base pattern design will be prevalent, even though WordPress is the initial target product that will be implemented. This is due to the fact that customizing FPS Ops for ServiceNow after the initial build would require extensive re-development. All family releases of the FPS Ops architecture will follow the A, B, C progressive naming convention (like the release cadence used by ServiceNow) with the inaugural release being named “Aloha.” Patches to the initial release will start with P1 (Patch 1) and proceed up to P9. After P9, if the patching ever makes it that far, a new family release should be developed binding in all of the patching to the current release. When referring to a specific release when a method is built, the blog term FPS [family release] or FPS [family release]-P[patch] such as FPS Aloha or FPS Aloha-P1 will be used – which is indicative of when the method or design was first implemented.
FPS Aloha will cover essential foundational elements required for establishing a new product instance “Services.” Key foundational services addressed in the FPS Aloha release include group and user management independent of AD, with an optional internal switch for AD integration if needed. Additionally, it will feature KeePass password management, multi-domain/instance data management, and multi-dimensional ownership assignments for product components. The release will also incorporate lessons learned from earlier versions of the platform, implementing changes that previously would have required a complete overhaul of the PowerShell platform – which was not practical for systems that were currently supporting active operations. Enhancements include a CICD aspect that obsoletes the previous build concept for container distribution, a re-imagined dynamic file location strategy, and the decoupling of the PowerShell modules. As a result, FPS Aloha will be fundamentally different from all prior Foundational Op releases, justifying the versioning reset back to the “A” release.
FPS Aloha, like all enterprise system components, should be initially designed and written from the Foundational Ops perspective (before establishing the product’s development instance), followed by the target products perspective (fScript, etc), and conclude with the integration of automations between them. This blog will follow that progression. The integration between on-prem VMs and the WordPress product will utilize “Local – Version 9.0.5+6706” and an evolving integration pattern. Currently there are no plans to integrate FPS Aloha with ServiceNow product, but will likely do so in the future using the developer ServiceNow instance to facilitate MID Servers integration utilizing PowerShell spoke actions. This integration is anticipated for the FPS Bermuda release.
Documentation related to the product infrastructure will be covered in the later blogs, while the initial blogs will focus on FPS Aloha. Foundational services using FPS Aloha and product automations will be discussed at the tail end of the FPS Aloha blogs, featuring a continually updated list of automations.
So lets kick it all off by designing the FPS Aloha Layer Identification!
FPS Aloha Layer Identification
[Key Insight B1.1] Each VM, server, or client running FPS Aloha employs two path structures: a source path and a runtime path. Although the source and runtime paths can be identical, the source path must remain uniform across all related VMs, servers, or clients using a given domain. The source usually resides in a shared cloud location for easy runtime access. In the FPS Aloha blogs the cloud area used will be Microsoft’s OneDrive with the runtime typically being the C: or D: of the target machine. For example, if Server A designates C:\Users\[UserId]\OneDrive as both the source and runtime path, then all affiliated servers within the domain must set C:\Users\[UserId]\OneDrive as their source path, regardless of their runtime path location. Typically, a VM, server, or client running FPS Aloha will use a shared cloud location for the source path and a distinct local FPS directory (often D:\FPS) for the runtime path.
NOTE: The FPS code will be created on a standard client and tested in a developer product instance, therefore, client-specific terminology will be prevalent. Readers must align this terminology with their enterprise or VM nomenclature used for their specific setup.
The FPS Aloha structure utilizes two base layers of abstraction within the source with a potential for 3+ more layers when describing its runtime paths within the blog entries. The root layer, Layer 0, is consistently designated as FPS. Layer 1 is divided into four main categories: Collections, Containers, Media, and Metadata. Each of these categories can contain layers 2 through n, depending on each layer 1 contextual element. The layers of abstraction will be noted within the blogs using a {[layer 1]:[layer 2]:[layer …]} notation. At times when the context of an individual blog entry always uses a the same root level 1 and 2, the root layers will be omitted for brevity. Although a particular file path can be derived from a layer notation (or its brief alternate notations), the notation does not account for all elements in the physical file path. Either the full or brief layer notation will be used when describing components in context with their locations within the FPS Ops blogs.
For example, the current layer lineage, its brief notation, and associated physical path’s are:
{FPS:Collections:KeePass} – brief notation {KeePass}, file path FPS\Collections\KeePass
{FPS:Containers:Common} – brief notation {Common}, file path FPS\Containers\[container version]\Common
{FPS:Containers:Common:Private} – brief notation {Common:Private}, file path FPS\Containers\[container version]\Common\Common\Private
{FPS:Containers:Common:Public} – brief notation {Common:Public}, file path FPS\Containers\[container version]\Common\Common\Public
{FPS:Containers:DataResources} – brief notation {DataResources}, file path FPS\Containers\[container version]\DataResources)
{FPS:Containers:DataResources:Private} – brief notation {DataResources:Private}, file path FPS\Containers\[container version]\DataResources\DataResources\Private
{FPS:Containers:DataResources:Public} – brief notation {DataResources:Public}, file path FPS\Containers\[container version]\DataResources\DataResources\Public
{FPS:Containers:Make} – brief notation {Make}, file path FPS\Containers\[container version]\Make)
{FPS:Containers:Make:Private} – brief notation {Make:Private}, file path FPS\Containers\[container version]\Common\Make\Private)
{FPS:Containers:Make:Public} – brief notation {Make:Public}, file path FPS\Containers\[container version]\Common\Make\Public)
{FPS:Containers:Services} – brief notation {Services}, file path FPS\Containers\[container version]\Services)
{FPS:Containers:Services:Private} – brief notation {Services:Private}, file path FPS\Containers\[container version]\Common\Make\Services)
{FPS:Containers:Services:Public} – brief notation {Services:Public}, file path FPS\Containers\[container version]\Common\Make\Services)
{FPS:Media} – {brief notation {Media}, file Path FPS\Media)
{FPS:Media:Logs} ‘- brief notation {Media:Logs}, file Path FPS\Media/Logs)
{FPS:Media:public_html} – brief notation {Media:public_html}, file Path FPS\Media\publix_html)
{FPS:Media:Scratch} – brief notation {Media:Scratch}, file Path FPS\Media\Scratch)
{FPS:Media:Web} – brief notation {Media:Web}, file Path FPS\Media\Web)
{FPS:Media:Web:Admin} – brief notation {Media:Web:Admin}, file Path FPS\Media\Web\Admin)
{FPS:Metadata} – {brief notation {Metadata}, file Path FPS\Media)
Each layer linage corresponds directly to a file or CmdLet “handle”. A CmdLet handle serves as the internal mechanism for identifying the correct active CmdLet within the versions and patches of a family release. When referring to a base layer in FPS Aloha within the filesystem, the handles will be organized in a similar manner to the layer construction only without an opening and closing brace { }. Instead, an opening and closing comment notation will be used <# #>.
For instance, the Make Layer 3 path in FPS Aloha Patch 1 has a coded handle of {FPS:Containers:Make}, while a CmdLet within layer 4 path would be coded as {FPS:Containers:Make:Public:Sync-FPS}. This nomenclature typically isn’t represented within the internal comments within the PowerShell code, except for line 1 where a variation of the handle is used to note the status of the CmdLet/Snippet/Encapsulation. The status handle will use comment notation <# #> with an additional status indicator. An example handle within a CmdLet file header would be <#FPS:Containers:Common:Public:Push-NeededFor:ACTIVE#>. This handle differentiates between three status identifiers – ACTIVE, DEVELOPMENT, and OBSOLETE. If ACTIVE appears on this line, the CmdLet is loaded when called as a file dependency for the current CmdLet. If OBSOLETE or DEVELOPMENT is present, the next patch level within the family (Aloha-P2, etc.) is searched until an ACTIVE CmdLet handle is found to load, continuing through all patch levels for all family releases. Only the last active version of the code will be loaded, even if a prior release is incorrectly marked as ACTIVE>
Versioning via handles in the FPS Aloha release is only used within the {FPS:Containers} layer. Other layer 1 subdivisions may, or may not, contain the header, but when present outside of {FPS:Containers} it should reflect an ACTIVE status because the code is not designed as a release dependent item.ready to be used. Since VMs can use the Source path as the Runtime path, all development must be marked as such so it is not loaded when needed. Once it is marked as Active, the BAHA code will be used the next time it is needed. The CmdLet will not be implemented via CI/CD to other CI runtime paths which allows for a slow role of a patch out to production.
Leave a Reply
You must be logged in to post a comment.