Google, Microsoft, Amazon, Oracle, WMware, IBM, RedHat están apostando fuertemente por estas tecnologías, ofreciendo todo tipo de servicios a los desarrolladores en la nube. Hoy por hoy todo va encaminado a ser dockerizado, como popularmente se refiere en castellano al hecho de empaquetar una aplicación software para ser distribuida y ejecutada mediante el uso de esos contenedores software.
|
etiquetas: docker , kubernetes , contenedores , openshift , microservicios , borg 
Voy a la |buambulancia a llorar porque esto es una pena.
Voy a la |buambulancia a llorar porque esto es una pena.
Y todo asi.
Se corre algo en linea de comando que no ves bien que, asumes que esta arrancado porque dice que asi lo esta.
No se, a mi parecer le falta interfaz grafica, que sea sencillo, se nota que viene del mundo gnu y te toca picar mierdas para arrancar un cochino contenedor.
Sera la falta de costumbre y estar acostumbrado a las VM.
Pero es solo mi suposición. A ver si asoma la patita y se explica...
Yo llevo ya 3 años con kubernetes en producción y me ha cambiado la manera de ver la infraestructura.... Más feliz que una perdiz
Y sí, me parece una auténtica revolución (una vez configuras el infierno inicial).
Pero Kubernetes es el infierno. No es fácil de configurar, muy difícil de encontrar errores y pocas instalaciones lo necesitan aunque todo el mundo quiere usarlo.
Soy ingeniero de software, lo mío es programar. Aprendí Docker en una mañana u me sentía cómodo en pocos días. Kubernetes es otro rollo, necesitas mucho esfuerzo para controlarlo y me distrae de mi principal tarea, que es crear software.
Pero bueno, curioso por lo menos, gracias #0, me lo guardo en favoritos para cuando me vuelvan a preguntar a qué hostias me dedico
Lo de picar líneas de comandos y su aparente asquerosidad es una tontería pero claro, tienes que saber qué le estás mandando hacer a la máquina y, para ello, primero tienes que saber los conceptos y empezar a mirarlo todo desde arriba, con un nivel alto de abstracción e ir bajando paulatinamente.
Este artículo mola porque te explica esos conceptos, el como te pelees con ellos desde más abajo, como dije antes, requiere un poco de esfuerzo.
Y es que es dificil mantenerse al dia en ésto de la informática (ahhh que tiempos los del COBOL y el BASIC
- ¿cómo se mete la aplicación en el docker?.
- ¿luego cómo se promociona el docker a producción?. ¿Con kubernetes?.
Nu se, oigo mucho hablar de esto, pero todavía no me ha quedado claro para qué sirve.
Docker container run!
Basicamente es parte de culpa que mucho programador se ha metido a temas de sistemas, sin tener ni idea (por tiempo o ganas) de saber como funcionan realmente los sistemas por debajo y todas las variables que conciernen a ello.
Mucha culpa de estos es los denominados ahora DevOps, que en su mayoria son más provinientes del DEV que de OPS. Es decir, gente con un conocimiento amplio de programación pero nulo de sistemas.
Haciendo que cosas banales y con costes irrisorios se conviertan en puros gasta recursos y con 0 optimización gracias a que lo que hay debajo da igual como funcione o lo que gaste, no es mi problema (pos ok).
Hemos pasado de empresas queriendo meter un wordpress que perfectamente podria costar 20$ mantener en un desarollo de casi 3 4k $ todo por querer meterlo microservicios. Y locuras así.
Y al final todo se resume en esto twitter.com/shanselman/status/968912658396098565
Para ejecutar la imagen en producción no se necesita kubernetes, se puede ejecutar en un docker engine. Para aplicaciones complejas con muchos contenedores, servicios y recursos se emplea Kubernetes, que sería el orquestador, vigila los contenedores y los despliega en el cluster. Pero también se pueden hacer despliegues más sencillos usando swarm, sin necesidad de kubernetes. Tienes un buen tutorial de inicio con ejemplos sencillos en la propia página web de docker.
docker crea un servidor, web, o lo que sea. la aplicacion la puedes meter con git, que se la descargue etc, o puede apuntar a una carpeta del sistema. o incluso a un disco en la nube, s3 lo que sea.
Un contenedor sirve para contener una aplicación y facilitar su instalación y ejecucion en cualquier entorno.
La VM puede servir para esto, pero es mucho más amplia, y no es tan eficiente en esa tarea concreta.
Conceptualmente y en terminos de uso son algo completamente distinto.
No es habitual loguearse dentro de un contenedor o instalar cosas después del momento de la creación.
Lo que haras será encapsupar una aplicacion dentro de ese y arrancarlo ... puedes acceder a los logs facilmente para confirmar que esta arrancado. No hay razón para asumir nada.
Si solo quieres dar clicks y ver colores, pues quizas vayas a tener dificultades pero googleando seguro que alguien ha hecho ya alguna GUI.
Suerte!
Detectado persona que no tiene ni idea, y que no quiere hacer el minimo esfuerzo en estudiar.
Si tu vida en IT depende de que otros te hagan una UI para que tu puedas dar click en YES, es que no eres generador de productos, eres un consumidor. Y no digas que debas armarte tus cosas en ensamblador.
Docker y Kubernetes esta suficientemente maduro, hay documentacion a chorradas y es ampliamente utilizado en empresas de alto nivel .
> Pero Kubernetes es el infierno. No es fácil de configurar, muy difícil de encontrar errores y pocas instalaciones lo necesitan aunque todo el mundo quiere usarlo.
Soy desarrollador de una distribución de kubernetes y estoy completamente de acuerdo. Kubernetes necesita un equipo especializado en kubernetes para administrarlo. Y desde luego me parece una locura montar kubernetes sin contratar soporte técnico, salvo que tengas gente capaz de tocar el kernel, kubernetes, el ingress controller que necesites, etc.
Para montar un cluster de media docena de nodos para ejecutar 500 pods ni te molestes en montar kubernetes.
Edito: Estoy de acuerdo en lo de que es complejo. No digo que no sea buena tecnología, como tecnología es la ostia, pero es una tecnología compleja que requiere un conocimiento y un volumen que no están al alcance de todo el mundo, y teniendo el volumen y el conocmiento tampoco cubre cualquier caso de uso.
Pero en algún momento las aplicaciones se volvieron más complicadas y empezaron a tener dependencias de DLLs, librerías, runtimes, intérpretes, compiladores, variables de entorno, ficheros de configuración, kernels...
Instalar una aplicación que joda a otras es relativamente fácil hoy en día. O que simplemente no puedas usar algo que requiere un intérprete versión X.Y pero tú tíenes instalado versión W.Z y si instalas una fastidias la otra.
Con un contenedor si te hace falta algo, una aplicación, un servidor, un servicio, lo bajas, lo das de alta en el sistema, lo ejecutas en un entorno controlado que no te va a hacer daño y lo usas, sabiendo que no te va a causar problemas con el resto de software en la plataforma y que el contenedor tiene todo preparado para que funcione a la primera. O si no está disponible en algún repositorio, te preparas tú mismo el contenedor y a tirar.
Esa idea es sencilla, pero potente, y evidentemente acelera muchísimo el ciclo de desarrollo, pero no sólo el desarrollo, ya que ahora es mucho más sencillo escalar las aplicaciones para atender las demandas de uso, ya que tienes una manera repetible y programable de poder ampliar la capacidad mediante un clonado exacto de la aplicación en un entorno controlado.
De nada, me alegro de que te haya gustado.
Igual algunos llevamos programando decadas y si hace falta pegarse con ello, lo hacemos. Pero me tocó bajar una imagen de esto y me tocó los cojones lo que me costó arrancarlo. Despues la url a la que apuntar, no funcionaba, despues noseque... Un puto desastre.
No voy a decir que era.
Y tengo docker para windows aqui mismito.
Podeis seguir con vuestros cliches.
Ejemplo de ahora mismo:
You are trying to run a container which is more than 90 days old.
Microsoft recommends that you always run the latest version of our containers.
Set the environment variable ACCEPT_OUTDATED to 'Y' if you want to run this container anyway.
he vuelto a hacer un "pull" de la imagen (que no tengo ni idea donde esta) pero nada.
Ahora,en google, busca una respuesta perdida de un foro...
–env accept_outdated=Y
Ah, espera que tampoco:
docker : C:Program FilesDockerDockerResourcesbindocker.exe: invalid reference format.
Y decis que es super sencillo y para toda la familia.. Hombre, tener que andar como si fuera MSDOS en 2019... no mola mucho la verdad.
Meto el comando docker accept_outdated, nada.
Y esto lo llamais facil y para toda la familia. Claro. En una consola de powershell ahi, y tirando de foros.
cc #59
Tienes las ventajas de poder optimizar los recursos con cgroups y de un mayor aislamiento que proporciona namespace, que da mayor seguridad y estabilidad al entorno.
También tienes la ventaja de que todo fichero de configuración o adicional que necesites lo puedes tener en la imagen. Si tienes la configuración por un lado y el binario por otro la portabilidad es mucho más compleja. Aquí levantas el contenedor y punto, está todo dentro.
Por último tienes las ventajas de nuevos productos como Istio, que te permiten hacer la leche de cosas con contenedores sidecar, aunque aún están algo verdes.
No entiendo el problema que describes; pero parece de la imagen, no de Docker.
Es que otros usuarios me han puesto de tonto para arriba diciendo que ni me molesto, cosa que he hecho cuando me ha tocado integrar con otros sistemas cosas. Ahora, que desde el punto de vista de un programador, tener que perder el tiempo para arrancar una mierda de imagen, me toca los cojones.
Me he ido a ver donde estan las imagenes, pues solo veo una carpeta llena de subcarpetas que se supone que osn las imagenes (C:ProgramDataDockerwindowsfilter) Y esto via respuesta de google de un foro de dios es cristo.
Asi no se puede andar.
courses.edx.org/courses/course-v1:Microsoft+DEVOPS200.4x+2T2019/course
Echale la culpa a MS, es bajada de ellos directamente. Siguiendo la puñetera ayuda.
Es que os repito, no podemos hablar de que algo mola la ostia cuando me estais diciendo que me haga un curso para arrancar una imagen que tenia parada mas de 90 dias. Ahora se me esta bajando otra nueva, creo. No se ni donde, pero bueno, ahi va, a algun sitio, desde algun sitio.
El resultado de los votos negativos es la misma portada día tras día. Da igual que la mires hoy o dentro de un mes. No vas a encontrar noticias diferentes ni nuevas páginas interesantes que investigar. Pero vamos, solo es mi opinión. Eso si, hay imbéciles como #67 que se empeñan en corroborarla con sus votos.
Docker no es nada complejo, salvo obviamente que tus imágenes estén mal construidas o no hagas las cosas bien. Kubernetes, como digo en #55, es otra historia. Eso sí es complejo, y mucho.
Set the environment variable ACCEPT_OUTDATED to 'Y' if you want to run this container anyway.
Primero, quien te da el error? El cliente de docker no? Pues la variable o te la pide el cliente, te la pide el servidor de docker/demonio.
Segundo, te pone ACCEPT_OUTDATED to 'Y', por que pones accept_outdated=Y ? Si te lo pone en mayúsculas para que lo cambias?
Por último y como como comentario no relacionado, aunque la libería estándar de go, GNU y Linux se lo comen, el estándar dice:
" Environment variable names used by the utilities in the XCU specification consist solely of upper-case letters, digits and the "_" (underscore) from the characters defined in Portable Character Set . Other characters may be permitted by an implementation; applications must tolerate the presence of such names. Upper- and lower-case letters retain their unique identities and are not folded together. The name space of environment variable names containing lower-case letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behaviour of the standard utilities. "
pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html
Ya veras cuando te unas a los mas cool's y modernos de nuestro exclusivo club de las tarjetas perforadas, esto es el futuro.
PD. Estoy con Femen, un USUARIO de contenedores no tendria que sufrir para usarlo.
Y todo esto para arrancar un cochino contenedor. OK.
Lo único que deberás tener en cuenta será el networking, si lo vas a hacer con mucho usuarios mantener el mapeo de los puertos a los contenedores te puede costar un poco.
> Y todo esto para arrancar un cochino contenedor. OK.
Siento las malas formas, pero si no entiendes exactamente el concepto de variable de entorno y como se heredan entre procesos, no es culpa de docker, es tu culpa tuya.
No se cuantos años llevan existiendo las variables de entorno pero tienen bastantes más años que yo y son un concepto fundamental, tanto en los derivados de Unix como en Windows.
> esto parece un foro linux donde todos te miran como si fueras subnormal por no saber configurarte la red local desde
> la consola y compilarte un driver bajado del repositorio de su puta madre.
Si hubieras dicho "tengo XXX problema, ¿Me podeis ayudar?", seguramente nadie te hubiera respondido como lo he hecho yo.
Pero si dices "Y decis que es super sencillo y para toda la familia.. Hombre, tener que andar como si fuera MSDOS en 2019... no mola mucho la verdad.", te expones a que te digan que es tu culpa por no saber conceptos imprescindibles para trabajar en un entorno POSIX.
Cualquier dia empezamos todos a hacer apt-get en windows, ya lo veras.
Y con los años me he seguido encontrando con personas que trabajaban en backoffice (administrando sistemas de MS), que si las sacabas de un entorno gráfico se sentían perdidas... en esos mismos departamentos había otras personas que hacían un uso intensivo de terminales de texto en cuanto tenían la opción!! y que conocían Bash mejor que yo (csh ya no tanto
Si la gente pasa un par de años formándose para administrar (incluso para programar) sistemas Windows, no siente curiosidad por otros OS y se encierra en eso que le enseñaron... acabará teniendo problemas; cada vez más, porque el ecosistema de servidores va hacia donde va y no es hacia MS (de hecho los que dirigen ahora MS, lo saben y ya están dando pasos hacia otra parte...).
En los procesos de migración en los que trabajé, no me ha extrañado encontrar usuarios que se se resisten a los cambios (cambios de aplicaciones y cambios de OS); pero si me extrañó bastante encontrar a profesionales en departamentos de informática también mostraban bastante resistencia al cambio (sobre todo cuando le llegó el turno al OS).
Me recuerda mucho a una ciudad española en la que, a principios de los años 80 había muchos talleres de mecánica (no servicios oficiales de marcas) que tenían carteles en los que rezaba (con más o menos fortuna ortográfica y sintáctica): "no se reparan vehículos de la marca Citroën"... En una ocasión le pregunté a un empleado por el motivo del cartel y me dijo que era porque se necesitaban tres o cuatro llaves articuladas y que los jefes no querían comprarlas... y que sin esas herramientas, las operaciones de mantenimiento llevaban bastante más tiempo.
Es la excusa ideal para separar la mierda y que cuando lo tengas que poner todo a correr las dependencias que genera cada subaplicación no te hagan tener ganas de cortarte las venas.
Gracias a docker la basura antigua no te quita el sueño.
Aparte, le puedes asignar una cantidad limitada de recursos para que ese engendro que hizo Calamidad Martínez no esté petando el sistena cada 48 horas.
Dicho esto... no es la solución a todo, leches!!!
Ahí es ná.