Cloud Foundry Blog |
|
Publicado: 06 de septiembre 2013 10:50 AM PDT
Buildpacks son el núcleo de la arquitectura de Cloud Foundry y nos han hecho recientemente importantes mejoras en el Cloud Foundry Java Buildpack . A medida que el desarrollador principal del buildpack, me gustaría darte una idea de los principios de diseño detrás de él, cómo utilizar, configurar y extiendo, y lo que depara el futuro.
Principios de diseñoEl objetivo principal de la buildpack Java es ser la forma más fácil de ejecutar una aplicación Java. 1 La palabra más sencilla puede significar muchas cosas, pero para mí significa que un desarrollador puede empujar una solicitud y tener una "simplemente funciona ™ "experiencia. Un desarrollador de aplicaciones no deberían tener que enredar con detalles como la configuración de memoria o la configuración del contenedor de trabajar con un servicio determinado. Gran parte de lo que hace el buildpack está infiriendo estos y otros detalles de forma automática, lo que ahorra tiempo a los desarrolladores y esfuerzo.Un objetivo secundario de la buildpack Java es para ser fácilmente extensible. No hay manera de que el equipo Foundry Java Experiencia nube puede tener la experiencia o el tiempo para apoyar a todos los contenedores, JRE y la integración de servicios. En su lugar, hemos diseñado el buildpack de tal manera que otros puedan ampliar lo existente e integrar los cambios ascendentes con el mínimo esfuerzo. Este diseño también nos permite integrar las contribuciones de la comunidad (que nos encanta!) de nuevo en la base de código fácilmente. El otro objetivo secundario del buildpack Java es ser agresivo hasta al día con las actualizaciones de seguridad de forma predeterminada. Muchas de las estrategias de implementación de aplicaciones requieren que los desarrolladores u operadores de aviso de que una revisión de seguridad ha sido puesto en libertad, y luego cambian su aplicación o entorno de ejecución de alguna manera a ser seguro. Los desarrolladores y operadores ya no tienen que preocuparse acerca de esto por las dependencias de infraestructura gestionadas por el buildpack (por ejemplo, Java, Tomcat, Groovy). El buildpack elige la última y más segura versión de dichas dependencias cada vez que una aplicación se empuja. 2 Si usted está preocupado de que este modelo no se ajusta a su aplicación, no se preocupe, que es configurable . Uso de la BuildpackA partir de hoy, la Buildpack Java está disponible para cualquier aplicación que se ejecute en el CF Pivotal servicio hospedado. La versión disponible de forma predeterminada será agradable y estable, adquiriendo características a medida que maduran, pero al mismo tiempo estar al día con los lanzamientos de dependencia de la infraestructura. Si usted es el tipo de persona que quiere vivir en el borde, se puede especificar la versión más reciente del buildpack al empujar 3 :cf push --buildpack https://github.com/cloudfoundry/java-buildpackLa documentación del buildpack describe qué tipo de aplicaciones se pueden ejecutar. Hoy esa lista se compone de las aplicaciones web (incluyendo Grails), Java main() aplicaciones, aplicaciones Groovy y Juega Framework para Aplicaciones .Configuración del BuildpackEn un principio podría entenderse como una sorpresa, pero la recomendación general es que los desarrolladores no deberían configurar el entorno que una aplicación utiliza cuando se ejecuta en Cloud Foundry. Ahora, entiendo que esta es una declaración de miedo para la mayoría de los desarrolladores de Java, pero darle una oportunidad. Hemos puesto mucho esfuerzo en hacer el buildpack "sólo trabajo" 4 . Si la aplicación no funciona fuera de la caja, por favor háganoslo saber y vamos a tratar de mejorar la buildpack para que lo haga.Si, después de dar la recomendación de no configuración de una oportunidad, usted decide que su aplicación requiere una configuración personalizada, es el momento de caer en el papel de operador. La configuración de la buildpack se gestiona de manera centralizada, y se compone de una colección de archivos YAML correspondientes a los diferentes componentes contenidos en el buildpack. Para cambiar esta configuración, la bifurcación buildpack 5 , editar la configuración y el uso del nuevo repositorio al empujar su aplicación 6 . Un tenedor buildpack debe ser visto como la configuración de una clase de aplicaciones en lugar de la configuración para una aplicación particular. Esa clase puede tener sólo una única solicitud en él, pero si usted se encuentra la creación de una serie de horquillas, es prudente dar un paso atrás y volver a evaluar la situación. Un principio rector del diseño es que un desarrollador puede esperar un impulso a "sólo trabajo", ya que es la responsabilidad del operador para proporcionar una buildpack (predeterminado o personalizado) que asegura que esto es cierto. Ampliación de la BuildpackEl buildpack se compone de un montón de funciones de coordinación y una colección de contenedores , JRE y marcos . Para agregar a esta colección, basta con crear una nueva clase de Ruby con la funcionalidad deseada y agregarlo a la lista de componentes . Cada tipo de componente ( contenedores , JRE y marcos ) tiene un contrato bien definido, se ejecuta en aislamiento del resto de los componentes, y utiliza un patrón de pizarra para comunicar sus contribuciones.Otro principio de diseño rector es que la ampliación de la buildpack debe ser un ejercicio aditivo, no un mutative. La principal ventaja de este principio es que los cambios ascendentes se pueden integrar fácilmente en un tenedor porque el punto de conflicto sólo es posible es un archivo YAML simple. Este mismo beneficio entra en juego cuando la comunidad contribuye cambios de nuevo a nosotros. Echa un vistazo a la colección de tenedores de algunos grandes ejemplos de personas que añaden soporte para Jonas , DropWizard y Karaf . Y, por supuesto, sería negligente si no mencionara la Libertad Buildpack de IBM . Si crea un componente que crees que es útil para otros usuarios de la buildpack, piense enhacernos saber y contribuir de nuevo a la comunidad. El FuturoSiguiente en la lista es el apoyo a los contenedores adicionales, y la integración automatizada de los servicios disponibles en el mercado CF Pivotal servicio hospedado. Más allá de que el futuro depende de ti, la demanda del cliente impulsa la lista de características para el buildpack, por lo que se oiga tu voz . También puedes chatear conmigo en la plataforma, la conferencia Foundry Nube , 8 a 9 septiembre, 2013. Allí estaré hablando buildpacks y la experiencia de Java en Cloud Foundry.Sobre el autorBen Hale es un Ingeniero de Software Senior en Pivotal, llevando la experiencia de Java en Cloud Foundry. Él puede ser encontrado en el VCAP-dev grupo ya través de cuestiones abiertas en eljava-buildpack proyecto. Él también hablará en laPlataforma y 2GX SpringOne conferencias en septiembre de 2013.
|
No comments:
Post a Comment