Este artículo proviene de un motor de traducción automática.

ALM Rangers

Visuales Studio ALM Rangers: Aumento de la fábrica de VM

Willy-Peter Schaub
Brian Blackman
Paul Meyer

Descargar el código de ejemplo

En este artículo, vamos a ahondar en la fábrica de Máquina Virtual (VM fábrica), explorando sus conceptos y ventajas.

Este artículo forma parte de una serie en la que los Rangers de Visual Studio ALM presentarán orientación para ayudarle a resolver problemas en entornos complejos y reales. Nuestro objetivo es ayudarle a mejorar la coherencia y la calidad de sus soluciones y el proceso general de gestión de ciclo de vida de aplicaciones (ALM).

En resumen, los Rangers son un grupo de expertos que promover la colaboración entre el grupo de producto de Visual Studio, servicios de Microsoft y la comunidad de Microsoft Most Valuable Professional (MVP) por la funcionalidad que falta resolver, eliminar bloqueadores de aprobación y publicación de mejores prácticas y orientación basada en la experiencia del mundo real.

La fábrica de VM (rangersvsvmfactory.codeplex.com) es la implementación de referencia de una solución de software y orientación asociado que automatiza la creación de entornos virtuales mediante una estrategia de fábrica casi completamente automatizado y consistente. El propósito de la fábrica de VM es desarrollar preceptivas alrededor de la virtualización, especialmente para Visual Studio, Team Foundation Server (TFS), administración de laboratorio y requisitos previos asociados. Los principales objetivos, como se muestra (con numeración correspondiente) en figura 1, son: (1) flexible basado en el esquema de automatización; (2) un escenario de creación simple clic virtual machine (VM); (3) una fábrica reutilizable que automatiza la instalación y configuración de entornos físicos y virtuales; (4) entornos consistentes y repetibles; (5) la capacidad de reutilizar entornos preconfigurados.

VM Factory Objectives
Figura 1 fábrica de VM objetivos

¿Qué no perseguir los objetivos de la fábrica de VM es una reducción en tiempo de compilación y configuración. Esto se llama un antipatrón.

Aunque la fábrica de VM es mucho más eficiente y disciplinado que una contraparte humana, el grueso del medio tiempo de generación se compone del momento de la instalación real, que no puede reducirse notablemente por la automatización. La iniciativa de la fábrica de VM se desprende el ecosistema de Rangers, que es reconocido por las limitaciones de entorno distribuido, a menudo pobres y desconectadas del ancho de banda que opera en (consulte el artículo de septiembre de 2011, "Visual Studio ALM Rangers: reflexiones sobre los equipos virtuales," a msdn.microsoft.com/magazine/hh394152). A pesar de compartir y Descargar máquinas virtuales por Internet es factible y es una práctica aceptada, puede ser un desafío en lugares donde el ancho de banda es un recurso escaso y caro. En lugar de invertir días o incluso semanas, para descargar una máquina virtual, la fábrica de VM permite imágenes idénticas a crearse de forma remota utilizando recursos locales. A pesar de las limitaciones que podrían tener recursos locales, se entregan estas imágenes recreadas con mínima o ninguna intervención del usuario

La entrega de imágenes consistentes es otra ventaja del núcleo a menudo olvidamos mencionar, pero es uno de los principales motivos de que los Rangers usan la fábrica de la máquina virtual. Los esquemas de imagen de flujo de una versión a otra, lo que significa que cuando creamos una nueva versión (v1.1) para solucionar un problema y, a continuación, otra generación para incluir una nueva versión del software (v2), sabemos la corrección y el nuevo software fluirá a versiones posteriores. Esto es especialmente útil cuando la próxima versión (v3) podría no ser construida por meses o incluso años. Cuando que transcurre mucho tiempo entre versiones, un equipo diferente podría ser asignado al proyecto. Si son imágenes consistentes en su lugar, la configuración de la secuencia de tareas de fábrica de VM y configuración de la estructura actúa como un documento vivo, con la que puede trabajar en el nuevo equipo.

Último pero no menos importante, la fábrica de máquina virtual permite la creación de imagen de demanda. Esto reduce los requerimientos de almacenamiento de disco de escritorio y equipos portátiles, así como la "angustia" sobre si una imagen de almacenamiento de información es la más actualizada.

Virtualización de Lab Management proporciona un flujo de trabajo automatizado para la generación, implementación y pruebas de software. La creación de estos entornos virtuales, requiere mucho esfuerzo manual. Actualmente tienes que configurar una biblioteca de VMs y plantillas para Microsoft System Center Virtual Machine Manager (VMM). Además, tienes que trabajar dentro de una topología de Lab Management.

El uso de la fábrica de VM significativamente reduce el esfuerzo necesario para crear las máquinas virtuales y VM plantillas. Más importante aún, la fábrica de VM facilita cambiar un sistema operativo o una aplicación que se utiliza para una VM o VMs plantilla. La fábrica de VM es fácil porque sólo tienes que cambiar una secuencia de tareas y, a continuación, ejecutar la recreación automatizada de la imagen. En la fábrica de VM, se conocen como imágenes de oro y funcionan como origen VMs para gestión de laboratorio.

Cuando se crea la máquina virtual, solicitará que seleccione la secuencia de tareas a ejecutar. Ofrecemos dos secuencias de tareas de Visual Studio ALM Rangers Lab Management, que analizaremos con más detalle más adelante.

Arquitectura de fábrica un vistazo

Como se muestra (con numeración correspondiente) en figura 2, la arquitectura de fábrica de VM puede ser alojado en (1) cualquier plataforma de Windows con mínimos requisitos previos, tales como un mínimo 1 GB de RAM y 100 GB de espacio libre en el disco dedicado a la fábrica de VM. La arquitectura se basa en la (2) Microsoft Deployment Toolkit (MDT), uno de los aceleradores de soluciones de Microsoft (bit.ly/tp5QX4). El Kit de herramientas proporciona un (3) consola de administración y comunes amplio herramientas y orientación para definir y gestionar la implementación de sistemas operativos y aplicaciones. Uso de secuencias de tareas (4), definimos la secuencia de pasos de instalación y configuración que se requieren para implementar un sistema operativo y las aplicaciones, como Microsoft Office, Visual Studio, (5) uso de scripts personalizados como los scripts de Windows PowerShell que se tratan más adelante en este artículo y (6) hacer referencia a los medios de comunicación para el sistema operativo y las aplicaciones a utilizar. Actualmente, la fábrica de VM supone que todos los medios de comunicación está físicamente presente en la fábrica de VM. Sin embargo, estamos investigando las opciones que nos permitirá hacer referencia a otras fuentes de medios de comunicación, tales como descargas de MSDN, para ofrecer una mayor flexibilidad y reutilización de los recursos existentes.

VM Factory Architecture
Figura 2 VM fábrica arquitectura

Cada fábrica de VM viene con imágenes de Litetouch CD arranque ISO (7). Estos le permiten iniciar una nueva instalación y conectarse al recurso compartido de implementación alojado en la fábrica de la máquina virtual. Durante el proceso de instalación y arranque, la secuencia de tareas apropiadas (8) está seleccionada. La secuencia de tareas define el software, la configuración y las secuencias de comandos que se aplican a la máquina de destino (9) durante la instalación de Litetouch guiado.

La fábrica de máquina virtual de Visual Studio ALM Rangers es una instancia de MDT prepopulated con secuencias predefinidas de tarea de fábrica. Estas secuencias de tareas construyen encima de las plantillas de secuencia de tareas MDT para el despliegue de equipo nuevo. Definen todos los pasos necesarios para crear una nueva máquina de metal desnudo (o bare metal virtual en caso de la fábrica de VM). A partir de dar formato a la unidad y la instalación del sistema operativo, los pasos seguir hasta (y incluyendo) la instalación de aplicaciones.

Las secuencias de tareas incluidas en la fábrica de VM son utilizadas por los Rangers para crear imágenes para demostraciones, pruebas de conceptos, prácticas y pruebas. A continuación se incluyen descripciones de estas secuencias de tareas:

  • Secuencias de Team Foundation Server base imágenes tarea definen todo incluidos Visual Studio imágenes que contienen ambas características de cliente y servidor TFS. También se incluyen Word 2007, Excel 2007, PowerPoint 2007 y, opcionalmente, Microsoft Office SharePoint Server (MOSS) 2007. En la fábrica de VM se incluyen secuencias de tareas para x 86 (basado en Windows Server 2008) y x 64 (Windows Server 2008 R2).
  • Secuencia de tareas de laboratorio gestión Hands-On Lab imagen define un entorno de demostración total para la administración de laboratorio. Se ha basado en x 64 imagen base de TFS, pero también contiene Active Directory, DHCP y VMM. DHCP es totalmente configurado pero desactivado por razones de seguridad. VMM y gestión de laboratorio de Visual Studio son ambos completamente configurado y sólo serán necesario agregar un host Hyper-V se unió el dominio al grupo de host predeterminado en VMM.
  • Secuencia de tareas de laboratorio gestión imagen base es útil para crear imágenes para probar el software utilizando Visual Studio Lab Management. Define una imagen basada en Windows Server 2008 R2 y instala Visual Studio Test Agent, controlador de prueba de Visual Studio, Visual Studio Lab Management Agent y Visual Studio Team Foundation Build. La mayoría de las configuraciones de prueba requerirá una combinación de estos agentes.

Cuando configura su propia fábrica, puede modificar estas secuencias a sus necesidades o utilizarlos como base para su propia secuencia de tareas personalizado. Para obtener más información acerca de cómo hacerlo, consulte la sección "Administración" más adelante en este artículo.

Automatización con Windows PowerShell

La fábrica de VM contiene scripts de Windows PowerShell desarrollados como parte de la iniciativa de fábrica Ranger para automatizar la instalación, configuración y optimización de los Rangers de Visual Studio ALM base de imágenes. Además de los scripts de Windows PowerShell y archivos CMD, hacemos uso de otro Microsoft servicios o aplicaciones de producto como ntrights.exe, stsadm.exe, psconfig.exe y iisreset.exe.

Planes de fábrica inicial llamados sólo secuencias de comandos de Windows PowerShell. Sin embargo, hemos aprobado MDT como los Rangers de Visual Studio ALM basan scripts de Windows PowerShell de imagen fábrica y llamada a realizar una configuración especial, optimización y ajuste de la configuración del MDT. Analizaremos algunas notas importantes y unas pocas fotografías de las secuencias de comandos, te dirige a la fábrica de VM para la fuente.

Para ejecutar los scripts de Windows PowerShell correctamente, debe tener Windows PowerShell instalado. Los scripts están diseñados para ejecutarse en Windows Server 2008 o versiones posteriores. Debido a que las secuencias de comandos no están firmados, y se requieren privilegios elevados para hacer cambios en el sistema, debe ejecutar el comando de Windows PowerShell "ExecutionPolicy conjunto irrestricto".

Si usas PowerGUI de powergui.org, que es un editor de secuencias de comandos y GUI de Windows PowerShell, las secuencias de comandos no se ejecutarán en modo de depuración. Se debe ejecutar en Windows PowerShell adecuada o mediante Alt + F5 mientras utiliza PowerGUI. Y por último, la secuencia de comandos de pre.ps1 1 requiere NTRights.exe, que se instala desde el Kit de recursos de Windows Server 2003. Sin NTRights.exe, vas a tener que desactivar las llamadas en las pasado algunas líneas del script en la función createTFSAccounts y manualmente establecer derechos de inicio de sesión interactivo para las cuentas de servicios TFSSERVICE y TFSBUILD (véase figura 3). Puede descargar las herramientas de Windows Server 2003 Resource Kit de: bit.ly/fbafh.

Figura 3 uso de NTRights.exe en una secuencia de comandos de Windows PowerShell

function createTFSAccounts
{
  blankline
  "Creating the 5 TFS accounts.
Namely TFSREPORTS"
  ", TFSSERVICE TFSBUILD,WSSSERVICE & SQLSERVICE with"
  " all their passwords set to P@ssw0rd"
  createUser "TFSREPORTS" "P@ssw0rd"
  createUser "TFSSERVICE" "P@ssw0rd"
  createUser "TFSBUILD" "P@ssw0rd" $true
  createUser "WSSSERVICE" "P@ssw0rd"
  createUser "SQLSERVICE" "P@ssw0rd"
  $currentLocal = Get-Location
# Set-Location 'C:\Program Files (x86)\Windows Resource Kits\Tools\'
  ./ntrights.exe +r SeInteractiveLogonRight -u TFSSERVICE
  ./ntrights.exe +r SeInteractiveLogonRight -u TFSBUILD
  Set-Location $currentLocal
}

Los scripts de Windows PowerShell instalados previos y viera contienen varias funciones que utilizan diversos objetos y escribir adaptadores, como el adaptador de interfaz de servicios de Active Directory (ADSI) tipo se muestra en la figura 4.

Figura 4 uso del adaptador de tipo Windows PowerShell ADSI

#Creates a user and sets the password to never expire
function createUser([String]$accountName, [string]$password, [bool]$delegated = $false)
{ 
  $computer = [adsi] "WinNT://$hostname" 
  $user = $computer.Create("User", $accountName)     
  $user.SetPassword($password)
  $flags = 65536 -bor 64
  if ($delegated)
  {
    $flags = $flags -bor 1048576
  }
  $user.put("UserFlags",$flags)
  $user.SetInfo()                                                       
}

El adaptador de tipo Windows PowerShell ADSI se utiliza para crear cuentas de usuario, definir las contraseñas y establecer la contraseña de admin no caduque nunca. Hay uso liberal de los cmdlets conjunto ItemProperty y nueva ItemProperty Windows PowerShell para manipular el registro para la fábrica de VM, como Habilitar búsqueda, establecimiento de la prioridad del programa y desactivar algunas de las características de confiabilidad de Windows Server 2003. Realizar estos cambios en el registro minimiza las tareas de configuración manual que se requieren para lograr los beneficios de la automatización, como se muestra en figura 5.

Figura 5 manipular el Rastreador de sucesos de apagado

function ShutdownEventTracker
{ 
  new-item 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Reliability'
    -erroraction silentlycontinue
  Set-ItemProperty –Path
    'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Reliability'
    -name "ShutdownReasonOn" -Value 0
  Set-ItemProperty -Path
    'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Reliability'
    -name "ShutdownReasonUI" -Value 0
}

Como mencionamos anteriormente, recomendamos que explorar el código fuente completo para que puedan entender cómo utilizar Windows PowerShell para automatizar muchas de las tareas como desactivar el protector de pantalla, desactivar el cortafuegos entrante, habilitar Escritorio remoto, desactivación de seguridad mejorada de Internet Explorer, que permite obtener super y cambiando el nombre del servidor.

Administration

Administración de la fábrica de VM es sencilla. Porque la fábrica de VM es básicamente un recurso compartido prepopulated despliegue de MDT, todas las posibilidades de la MDT están a su disposición para personalización o extensión. La principal herramienta para la administración de recursos compartidos de distribución MDT es Deployment Workbench. Los temas de ayuda documento Deployment Workbench muy bien, pero listo para imprimir documentación puede descargarse desde go.microsoft.com/?linkid=9707467. Le proporcionaremos una breve descripción para empezar.

Al iniciar el Deployment Workbench, está presentado con la familiar interfaz de usuario de la consola Administración como se muestra en figura 6. En el panel izquierdo, expanda el nodo acciones de implementación. Si siguió las instrucciones de la guía en CodePlex correctamente, debe disponerse la "cuota despliegue VSTS Rangers". Si no es así, puede abrirlo ahora mediante la acción apropiada en el panel de la derecha.

Deployment Workbench Administration Interface
Interfaz de administración de la figura 6 Deployment Workbench

Echemos un vistazo a figura 6. Al ampliar el compartir de despliegue de Rangers de VSTS, puede examinar el contenido del recurso compartido de distribución. Esta es una vista fácil de los archivos XML en el directorio de Control del directorio de recurso compartido de implementación en el disco. Aplicaciones, sistemas operativos y secuencias de tareas son nuestros principales puntos de interés. Cuando realiza cambios en la configuración de uso compartido de implementación, debe seleccionar Update Deployment Share. Esto regenera las imágenes de arranque que se utilizan para iniciar cualquiera de las secuencias de tareas.

Definiciones de aplicación describen dónde se encuentran los archivos de origen para una aplicación en el recurso compartido de distribución y cómo instalar la aplicación mediante el comando de instalación silenciosa, como se muestra en figura 7. El comando no requiere ninguna interacción con el usuario para completar la instalación. A veces esto requiere que prepare la instalación mediante la creación de una secuencia de comandos de instalación desatendida. En caso necesario, los Rangers ya han hecho para las aplicaciones en la fábrica de la máquina virtual.

Task Sequence Task Details
Figura 7 detalles de la tarea de secuencia de tareas

Las definiciones de OS, el MDT es capaz de extraer toda la información necesaria desde el origen de instalación de OS. Normalmente, un conjunto de archivos de código fuente contiene archivos para varias versiones de un sistema operativo. Las diferentes versiones se mostrarán bajo los sistemas operativos y pueden ser seleccionadas para la instalación en secuencias de tareas.

Las secuencias de tareas incluidas en la fábrica de VM, se ha descrito anteriormente, se encuentran bajo el nodo de secuencias de tareas. Ver las propiedades de una secuencia de tareas le permite modificar la secuencia de tareas propiamente dicho. Figura 8 demuestra que secuencias de tareas está dividida en varias fases. Las fases importantes son la fase de instalación que instala el sistema operativo, y la fase de restauración del Estado, que controla todas las instalaciones de post-OS. La barra de herramientas proporciona opciones para añadir o quitar pasos de la secuencia de tareas. MDT proporciona varios pasos diferentes. Figura 8 también muestra las propiedades de una tarea de instalar aplicaciones.

Task Sequence Properties
Figura 8 propiedades de secuencia de tareas

Ampliación de la fábrica de VM

Ampliación de la fábrica de VM también es sencillo. Analicemos los pasos básicos para agregar otra herramienta a la imagen. Como ejemplo, añadiremos la herramienta de poder de métricas de código (microsoft.com/download/en/details.aspx?id=9422) a la secuencia de tareas. La herramienta se instala un ejecutable llamado MetricsSetup.exe. El proceso consta de los siguientes pasos:

  1. Determinar la línea de comandos de instalación silenciosa para la aplicación
  2. Solicitud de copia al recurso compartido de implementación
  3. Iniciar MDT Deployment Workbench
  4. Crear nueva definición de aplicación
  5. Agregar aplicaciones a la secuencia de tareas
  6. Probar la secuencia de tareas actualizadas

Paso 1 es averiguar cómo instalar esta herramienta sin interacción del usuario: una instalación desatendida. Podríamos mirar la documentación del producto para obtener información de instalación desatendida. ¿Otro método que generalmente nos da un indicio es ejecutar el archivo con /? ¿o -? como argumento. ¿Cuando ejecutamos MetricsSetup.exe /? desde la línea de comandos, el cuadro de diálogo uso cuadro figura 9 se muestra. Verificamos que la línea de comandos de instalación silenciosa es MetricsSetup.exe /q esto ejecutando en un equipo de prueba.

Result of Running MetricsSetup.exe /?
¿Figura 9 resultado de ejecución MetricsSetup.exe /?

Paso 2 es mover o copiar el software en la ubicación correcta en el recurso compartido de distribución. Para ser coherente con el resto del software en la parte de implementación, creamos un directorio llamado "C:\Deploymentshare\INSTALL – código métricas poder Tool\Source\" y copiar el archivo ejecutable al nuevo directorio.

Ahora que los archivos están en la ubicación correcta, empezamos el MDT Deployment Workbench (paso 3) Añadir la definición de aplicación (paso 4). Desde la vista inicial del MDT (véase figura 6), nos encontramos y seleccione el nodo aplicaciones del panel izquierdo y elija Nueva aplicación. Un asistente nos ayudará a crear la nueva definición de aplicación. En la primera página del asistente, elegimos "Aplicación sin archivos de código fuente o en otra parte de la red," porque ya pasamos el archivo ejecutable para la ubicación correcta.

En la siguiente página del asistente, tenemos que introducir el nombre de la aplicación que se mostrarán en todas las interfaces y algunos datos adicionales y opcionales que no se utilizan en el proceso. La última página del asistente en el proceso de definición de aplicación es entrar en el comando de instalación silenciosa y el directorio de origen (véase figura 10). Tras finalizar al asistente, encontrará la nueva aplicación en la lista de aplicaciones.

New Application Wizard: Defining Command Details
Figura 10 nuevo Asistente para aplicaciones: Definir detalles del comando

Para instalar la aplicación, tenemos que añadir un paso a una secuencia de tareas (paso 5). En el editor de secuencias de tareas, busque la ubicación donde desea agregar la acción de instalación. En el menú Agregar de la barra de herramientas, seleccione General | Instalar aplicaciones para añadir una nueva acción a la secuencia de tareas. En el panel de propiedades a la derecha, seleccione "Instalar una sola aplicación" y haga clic en Examinar para seleccionar la aplicación de la herramienta de poder de métricas de código. Haga clic en Aceptar para guardar la secuencia de tareas. Estamos listos para la prueba (paso 6).

La guía más reciente

Ya sabes todo lo que necesita saber para empezar a ajustar su cuota de implementación a sus necesidades específicas.

Puede encontrar las últimas orientaciones y despliegue compartan plantillas en CodePlex (bit.ly/aL0mxZ) y una tabla de contenido de blogs asociados, vídeos y otra información en el blog de Rangers (bit.ly/qEIRPl).

Habiendo comprobado los conceptos y la viabilidad técnica de la automatización y la consistencia de la fábrica de VM, estamos planeando las siguientes mejoras:

  • Una fácil implementación y administración de nuevas fábricas
  • Mantenimiento más amigable y controlado de fábricas existentes, tras los grandes principios de la iniciativa de implementación hidratación
  • Capacidad para programar la automatización de fábricas
  • Capacidad para utilizar bibliotecas de medios de comunicación existentes, como las descargas MSDN, en lugar de duplicar los medios de comunicación en cada fábrica

Estad atentos que seguimos mejorar esta herramienta vital.

Brian Blackman es consultor principal con el equipo de Microsoft Services Partner ISV, centrándose en que afectan el éxito de los socios ISV en ingeniería y en el mercado. Él es un CSM, MCSD (C++), MCTS Visual Studio ALM Core Ranger. Pasa su tiempo escribiendo código, crear y ofrecer talleres y consultoría en diversas concentraciones y todas las cosas ALM.

Paul Meyer es consultor senior de aplicaciones plataforma con servicios de Microsoft en los Países Bajos, con un fuerte énfasis en el procesos de desarrollo y herramientas. Él ha participado en proyectos de Visual Studio ALM Rangers durante varios años.

Willy Peter Schaub es un senior program manager con los Rangers de Visual Studio ALM en Microsoft Canadá desarrollo centro. Desde el mediados-'80s, él ha sido buscando simplicidad y mantenibilidad en ingeniería de software. Su blog es en blogs.msdn.com/b/willy-peter_schaub y él está en Twitter en twitter.com/wpschaub.

Gracias a los siguientes expertos técnicos para revisar este artículo: Vladimir Gusarov, Bill Heys, Bijan Javidi, Zayd Kara, Vijay Machiraju, Robert MacLean, Rui Melo y Patricia Wagner