Series:
(Disclaimer: The
manuscript is my personal view and is not affiliated to any groups or
organizations)
In the first phase it is recommended to stay focus on the
learning ramp-up and don’t make any significant changes in the core operational
infrastructure such as source code control, CMDB server, CI Server, etc.
especially if these servers are shared resources used for other projects which
have their own migration timeline to Cloud.
Try not change the build and release process extensively.
Try not to change the build infrastructure in this phase. By doing so there is
no change needed for the source control along with the recipes (or assets) of
CMDB, etc.
However, DevOps should start preparing the CM tools such as
Puppet or Chef recipes and commence modifying the deployment scripts captured
as Infrastructure as a code maintaining revisions in source control. There are
many choice to write the infrastructure code such as using SDKs (in a variety
of language flavors), CloudFormation (in case of AWS), Azure Resource manager,
boto (a python AWS package), etc.
Cloud VMs should
have necessary client tools (Chef or
Puppet) installed. Ensure that copr firewall has been configured to
allow bidirectional traffic. Keep on using the same build infrastructure.
Please note that it is prudent to set up Azure cloud service
with static IP so that the IP could
be used in the firewall and that it eliminates the need to update firewall if
the IP changes. Also, note that as long as there is a VM running inside the
Cloud service the IP is not released in case static IP address is not selected.
However, it is (if not should be a) common practice to not to keep running the
non-production environments such as dev, qa, performance test, stage, etc all
the time. This is an efficient use of Cloud…and save money…Azure automation can
be used to shutdown and start the concerned VMs (of non-production
environments) at scheduled timing. Azure automation doesn’t need a dedicated
launch pad otherwise which could be used as an alternative to automation.
CI servers/masters shouldn’t be altered rather should be
configured with necessary plug-ins to push code to the VMs in Cloud. Azure
provides both Chef recipes and Puppet modules.
However, at times if DevOps need to invoke a startup script
while the VM is starting to ensure that the VM is in a desired state (with
correct config and code either from CMDB/CI or via a custom deployment process)
before the VM is ready for use. In this case VM extension (or user data in case of AWS) should be used to pull
the script from Azure Storage. The startup script then could pull the
compressed (or not) from Azure storage. The CI or custom build script could
push the build to Azure storage (or AWS S3). Use Azure block blob and not page
blob.
Automated test launch pad could be either the same one used
before migration or could be a VM sitting inside Azure or could be Azure
automation PaaS or could be Azure batch PaaS. See if you can reuse
existing test bed and launch pad in the first phase.
The whole idea is to “reiterate” with minimal changes be
Cloud ready…the subsequent phases will further improve the progress make
progress towards becoming complete Cloud oriented.
Turn on analytics, collect logs, and have automated process
(such as simple crontab) push those logs to Storage. If application is using
asynchronous mode of logging such as a queue infrastructure the setup that
infrastructure in cloud and have the message broker (in case of Azure Service
Bus) write to Azure storage or have the message consumer (in case of Azure
Queue) write to Azure storage. Use either a program of available UI to access
the logs. Azure storage explorer (or S3 browser in case of AWS), etc. to
quickly access the logs.
 |
| Build & Deployment network diagram |
No comments:
Post a Comment