edición general
350 meneos
cerrado
7317 clics
Entendiendo qué son los contenedores y por qué es una de las mayores revoluciones de la industria del desarrollo

Entendiendo qué son los contenedores y por qué es una de las mayores revoluciones de la industria del desarrollo

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
«12
  1. Un artículo explicando de forma muy clara y amena una de las grandes revoluciones de la informática en los últimos tiempos y a nadie le interesa y uno hasta vota "errónea". xD

    Voy a la |buambulancia a llorar porque esto es una pena.
  2. #25 Es que normalmente el management oye las “buzzwords” del momento y lo quiere ya y sin rechistar:  media
  3. #4 Que complejidad???  media
  4. #1 Los votos negativos son un cáncer. Son los responsables de haber convertido Menéame en la basura que es hoy día. Hace ya mucho tiempo que esos votos no tienen ningina utilidad.
  5. #5 yo supongo que se refiere a que hay mucho hype alrededor y eso hace que mucha gente intente meter esta tecnología con calzador allá donde de momento no es tan útil y los paradigmas tradicionales funcionan mejor

    Pero es solo mi suposición. A ver si asoma la patita y se explica... :-D

    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
  6. #8 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.
    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 .
  7. #8 Menos mal que has hecho este comentario en Meneame y no en Linkedin. Con todo el respeto, un profesional de IT que en el contexto de la mejora de la automatización llora porque echa en falta una interfaz gráfica no lo contrataría jamás y creo que nadie con dos dedos de frente y una mente mínimamente innovadora.
  8. #8 :-| Hablas de docker? dificil de montar por cli? pero si es una chorrada, y gestionar los docker tambien es sencillo. Ademas, tienes una cantidad ingente de aplicaciones alrededor para gestionar
  9. #21 En cierto modo, la idea de los contenedores permite volver a los "tiempos felices", cargabas el programa, ejecutabas y listo. Quien haya manejado el Spectrum se acuerda: LOAD "" y a jugar. O teclear el ".exe" y ya.

    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.
  10. Qué manía de contraponer los contenedores con las máquinas virtuales, cuando son tecnologías diferentes y que se complementan. Las máquinas virtuales tienen un mayor grado de aislamiento de los recursos que los contenedores, así que combinando despliegues de docker y VM para diferentes aplicaciones se incrementa la seguridad (a costa de perder algo de rendimiento, todo sea dicho). De hecho yo cuando diseño arquitectura de alguna solución en cloud suelo mezclarlos, metiendo los servicios que necesitan más chicha en Docker desnudo, y los que necesitan más seguridad en clusters de docker sobre OpenStack.

    Pero bueno, curioso por lo menos, gracias #0, me lo guardo en favoritos para cuando me vuelvan a preguntar a qué hostias me dedico ;)
  11. #8 Tu comentario es bastante confuso y se dejan ver horas de frustracion ... pero creo que tu problema es que intentas usar contenedores como usarias VMs y son un concepto completamente diferente.

    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!
  12. #12 Estamos todos esperando a que nos muestres tu desarrollo, que seguro es mucho mejor...
  13. Docker y Kubernetes está muy bien, pero el problema es que a veces es matar moscas a cañonazos y metes sobre-arquitectura en lo que es una aplicación sencilla porque querer dockerizar todo. Montar la infraestructura para kubernetes y que permita escalar horizontal y verticalmente no es baladí.
  14. #64 supongo que te refieres a un binario con todas sus bibliotecas embebidas estáticamente.

    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.
  15. #8
    > 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.
  16. #27 totalmente falso.
  17. #69 Claro que la miro. Es la única forma de que Menéame merezca la pena, mirar la cola de noticias. Lo que a ti te parece mierda a otro le puede parecer interesante. Si no me interesa, no entro y punto. Pero no ando votando negativo. Si votara todo lo que no me interesa votaría negativo el 95% de las noticias de portada. No lo hago porque entiendo que hay gente a los que les interesa.

    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. xD
  18. #84 con una interfaz de línea de comandos puedes hacer scripting, e integrarla con un orquestador es trivial. Con una interfaz gui no.

    La tendencia es a automatizar procesos, no a contratar a más gente para poder hacer click en más botones a la vez.
  19. #1 A mí me ha ayudado, tenía una cierta idea pero no las había aterrizado. Gracias.
  20. #5 Docker es cojonudo. O cualquier otro sistema de containers. Permite especificar la configuración de la aplicación de manera unívoca, algo que antes había que documentar y no siempre era obvio. Ahora, arranco un contenedor en casi cualquier máquina y, voilà todo funciona.

    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.
  21. #23 Si...eso pienso. Docker es el pequeño esfuerzo que debe hacer el programador para ayudar al sysadmin y Kubernetes la aproximación del sysadmin al desarrollador.
  22. Es gracioso el tema, porque hemos pasado de pensar las cosas con cabeza a intentar meter las tecnologias con calzador, por modas.

    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
  23. Es como muchas cosas en informática. Requiere tiempo y estudio.
    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.
  24. Atención, preguntas de novato total:
    - ¿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.
  25. #1 Hombre... No es que a nadie le interese, pero yo me he leído el artículo y pese que tengo los conocimientos mínimos para montarme mis propios PCs y usar Linux a nivel básico, no he entendido un carajo. Si es una cosa útil adelante, y seguro que a los informáticos reales les resulta de utilidad, pero es un artículo al que le falta algo de masa crítica en cuanto a público (aunque parece que ha cogido más fuerza).
  26. #14 O tambien conocido entre los recruiters como "Dockers". :shit:
  27. #88 No, si ya se lo que es una variable de entorno, 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.
  28. #182 has fallado en todo. :-D
  29. #184 bueno, también esperaba las respuestas correctas.
  30. #186 aquí, por poner solo un ejemplo, viene bien explicado. Si no sabes inglés dime y te busco una página en español, pero vamos, en Google te salen miles. :-)
  31. #187 no estaba tan perdido como pensaba. Cgroups sí es para permisos/gestión de recursos pero de hardware y namespaces pensaba que era diferente del de linux y simplemente es replicar toda la configuración, como si fueran instalaciones diferentes.

    Lo de sidecar no lo he visto en el enlace que me has pasado. Pero ahora sí tengo tiempo así que lo busco yo.

    Gracias por todo.
  32. #188 un pod "sidecar" es lo que mete por ejemplo Istio (no te canses mirando mucho Istio porque eso sí que es un follón).

    La unidad de computación mínima de Kubernetes no es el contenedor, sino el pod. Un pod consta de uno o varios contenedores que comparten ciertos namespaces. Eso da flexibilidad para hacer ciertas cosas.
  33. #2 me alegro. Esa era la idea. Creo que para la complejidad del tema está explicado de forma muy ilustrativa.
  34. Nada mejor que Citrix. :troll:
  35. #21 Lo dices como si COBOL ya se hubiera extinguido.
  36. Yo todas las pipelines de datos las ejecuto a base de DAGs de Apache Airflow, sobre Kubernetes.

    Y sí, me parece una auténtica revolución (una vez configuras el infierno inicial).
  37. #22 Con Docker se construye la aplicación con un Dockerfile que declara las dependencias e instrucciones para crear una imagen (una imagen es un “archivo” de solo lectura que empaqueta el software y las dependencias. Esa imagen se almacena en el registro local donde se construyó, y se puede subir a repositorios públicos como harías con git (tiene de hecho una sintaxis similar).
    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.
  38. #18 hay nuevas soluciones de contenedores que incluyen sistemas operativos como Red Hat Core OS, en los que una máquina virtual ya no sé si aporta alguna seguridad extra.

    De nada, me alegro de que te haya gustado.
  39. #58 #54 #40 #39

    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.
  40. #9 Ese tipo de comentarios ya los oía yo a finales de los 90 cuando impartía unos módulos acerca de cómo compilar el kernel Linux y el kernel FreeBSD a gente que estaba en medio de un "máster de redes y servidores" con certificación de MS.

    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.
  41. #112 no exactamente. Docker no ejecuta nada, sino que construye imágenes y las arranca, pero estas corren directamente sobre el sistema operativo.

    Un contenedor no es más que una serie de procesos del sistema anfitrión encerrados; esto es, que su relación con el resto del sistema anfitrión está limitada. Por ejemplo, los procesos del contenedor no pueden ver el resto de procesos del sistema.
  42. #32 Istio es un sindiós. Debe de haber 10 personas en binario que lo comprendan en el planeta.
  43. #111 #123 Gracias por la respuesta.

    He usado OpenStack y no me parece sencillo para nada. Sólo la instalación ya requiere muchísimo tiempo, más luego que no salte algo por los aires al actualizar... sólo lo volvería a usar si tuviera algo muy, muy gordo. Mejor dicho, si hubiera varios sysadmin para que lo hicieran ellos.

    La verdad es que, después de haberlo probado con minikube, me pareció que no era tan mala opción para algo como lo que suelo hacer, de tener varios servidores (menos de 10), y que así tenía una solución más o menos estándar, en vez de reinventar los mismos scripts, recetas de Chef, etc.

    Ignorando la parte de instalación, que podría encontrar algún proveedor que lo diera ya hecho, ¿os parece que el mantenimiento de varias aplicaciones es complicado o pesado?
  44. #162 es una pregunta que no tiene una respuesta exacta. Si lo instalas, funciona, no lo tocas y no cambias muchas cosas puede que no dé tanto que hacer. Sin embargo, Kubernetes es una herramienta donde puedes configurar muchísimas cosas y donde hay muchos componentes interaccionando. Es una herramienta muy modular y muy compleja. ¿Qué quiero decir con esto? Que yo no instalaría algo así en producción sin un contrato de soporte detrás, personalmente.
  45. #163 Gracias por tu opinión. Pero ahora mi duda iba más enfocada a usar un Kubernetes alojado por algunas empresas (por supuesto, Google nunca), y si esto sería un dolor de gestionar también o podría quedarme con lo que sería nuestro uso:
    - Despliegues usando contenedores en vez de scripts y demás
    - Distribuir la carga entre contenedores distribuidos entre varios servidores
    - Un sistema que se pueda replicar para otros proyectos con pocos cambios, en vez de hacer las cosas ad-hoc
    - Potencialmente en el futuro, poder crear contenedores para dotar de nuestro servicio a los usuarios cuando contratan y destruirlos cuando se dan de baja.
  46. #164 de nada, un placer.

    En ese caso, la complejidad sigue siendo la misma a nivel de plataforma, solo que en vez de hierro estás en una nube.
  47. #26 Cierto, ahí sigue... si es que lo que es bueno... :-D
  48. #63 No seré yo quien defienda docker (creeme, he sufrido y mucho ciertos detalles de implementación) pero esto es que tu no estás interpretando un error bastante claro. Te está diciendo:
    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
  49. #102 #111 para cosas pequeñas también tienes Docker Swarm.

    Kubernetes creo que es una solución ideal para cosas muy grandes. De lo contrario es matar moscas a cañonazos. Y aun siendo grandes, como dice #111, si ya funcionan con otra plataforma a lo mejor es mejor no tocar.
  50. Docker y Kubernetes. Lo mejor y lo peor de la actualidad tecnológica.
  51. Ah y se me olvidaba esta maravilla que resume lo que son los microservicios también. twitter.com/samcres/status/1171440961932521478/photo/1
  52. #1 Entro, veo que no va de contenedores marítimos y os dejo con vuestra movida.

    Pero ni se me ocurre votar negativo.
  53. #5 yep, docker + docker-compose + traefik es mi stack

    Kubernetes es un infierno para echarlo a andar en servidores dedicados, y en mi entorno de desarrollo local.

    No me interesa desplegar en Kubernetes en aws, o gcc si no puedo desplegar en Kubernetes en local, y muy importante también en dedicados.

    Échale un ojo a traefik. He desterrado a nginx.
  54. #149 sin duda.

    Pero a esas escalas hay recursos para tener un especialista en Kubernetes.

    A mí que estoy startupeando, Kubernetes me viene grande.

    Tengo 3 servidores dedicados con balanceo de carga por dns, y en cada uno de ellos traefik, y un docker compose por cada startup.

    Una de las gracias de traefik es que te olvidas de asignar puertos etc.

    La otra que lo configuras en el docker compose del proyecto. De modo que toda la configuración del despliegue vive en un único archivo.
  55. #155 sé que balanceo por dns no es lo mejor. No tiene, por ejemplo, en cuenta la carga de cada servidor ya que es cada navegador por su cuenta quien decide a que ip enviar las peticiones.

    La tolerancia a errores es buena en caso de que se caiga el servidor, pues el navegador prueba con otra ip, pero no tan buena en caso de que se caiga el servicio y el navegador recibe un 404 de traefik, ya que el navegador no entiende que el 404 es por la ip, sino por el recurso.

    En estos momentos tengo bastante carga de desarrollo, cuando baje un poco miraré docker swarm a ver si me encaja.

    Gracias.
  56. #170 Y fue echada de ella como se debe, con mas votos negativos que positivos.

    Lo inaceptable, y lo que ocurre, es que unos pocos votos puedan sacar noticias de portada o impedir que lleguen. Como estos casos.

    www.meneame.net/story/aportan-hoy-dia-politicos-sociedad

    www.meneame.net/story/puedes-llamarlo-responsabilidad-pero-censura

    www.meneame.net/story/juventud-sin-futuro-tambien-sin-pasado-falsas-pr

    En fin, allá el dueño con sus ridiculas decisiones, que se esta cargando su propia página.
  57. #27 Iba a ignorar la noticia, por su nula calidad, y escasa visión crítica, pero tras tu comentario he optado por negativizarla.
  58. #96 ahora lo tengo así, pero sin un chroot, como les des permiso a la función system por ejemplo te pueden ejecutar cualquier cosa que esté instalada en el servidor. Por eso me interesa lo de Docker. Parece fácil tener un sistema sólo con lo necesario
  59. #123 Que tal va Swarm? yo lo probé cuando llevaba unos pocos meses con kubernetes (empecé en la 0.X a mediados de 2015 o así que tuvo que ser a finales de 2015 o principios de 2016) y me pareció una puta mierda, pero claro, el proyecto tenía unos pocos meses
  60. #53 Red Hat CoreOS lleva un kernel linux normal y corriente. Es aislamiento es inferior al de una VM.

    La gente de Red Hat estaba metiendo mucha historia en lo de rootless containers, rootlesss builds (que luego necesitaban setcap así que al final rootless por mis cojones pero bueno), se supone que el trio cri-o/podman/buildah era algo más seguro que docker/containerd y debería tener una política de SELinux y seccomp bastante buena, pero al final vamos, que al final no deja de ser un linux normal y corriente ejecutando procesos "enjaulados" con namespaces, cgroups, SELinux y seccomp.

    #105 No, en el caso de RHCOS son contenedores. Hay ciertos runtimes de OCI que no son lo que se entiende contenedores al uso, por ejemplo kata containers construye una vm con un kernel mínimo y le plancha el contenedor en ese kernel.
    Luego hay movidas raras que no son contenedores al uso, hay uno llamado gvisor que es un contenedor y le meten una capa adicional que intercepta ciertas syscalls (creo recordar que primero lo implemetaron con ptrace y luego hicieron alguna optimización con ebpf pero nunca llegué a entender como funciona internamente, no soy especialista en el kernel). Pero en el caso de RHCOS usa la misma tecnología por debajo que docker (aunque seguramente con unos valores por defecto más sensatos)
  61. #171 tengo entendido que con CoreOS el sistema operativo es inmutable, de solo lectura según creo, con lo cual supongo que es más difícil atacarlo desde un contenedor. Lo que quizá sea igual es un ataque o una escalada de privilegios de contenedor a contenedor.
  62. #173 Ni el antiguo container linux, ni RHCOS ni RHEL atomic son realmente inmutables.
    RHCOS utiliza OSTree para ser "inmutable", que lo que hace es que cuando reinicias restaura el estado previo (salvo que fuerces un nuevo ostree, que no recuerdo como se hace exactamente). Pero, si eres suficientemente listo para saltarte el sandbox, tambien lo eres para hacer cambios persistentes. Además no todos los directorios los gestiona con OSTree, por ejemplo /var y /etc si son mutables.

    Está enfocado a evitar diferente versionado, permitir hacer rollback después de un upgrade, etc... No es un mecanismo de seguridad al uso.
  63. #176 interesante. Desconocía esos detalles. Gracias.
  64. #24 Existen docker para windows nativos a partir de Windows Server 2016 si no recuerdo mal.
  65. #97 "habrá quien use mal los votos, pero hay mucho spam/sensacionalismo"

    Lo que tu llamas "sensacionalismo spam" mucha gente puede considerarlo "noticias interesantes"

    El problema es que unos pocos puedan tirar una noticia interesante con tanta facilidad.
  66. #172 Tu forma de actuar me parece genial, pero eres una raya en el océano de votos de Menéame. En mi opinión la inmesa mayoría no actúa como tu. Creo que esto es algo obvio.

    Por otro lado soy partidario de que las noticias sensacionalistas, erróneas, etc suban a portada. La razón es muy sencilla, no soy experto en todo y me gusta saber el porqué de las cosas. El mayor valor de Menéame son los comentarios (o mejor dicho eran) y entre la gente que comenta siempre hay gente dispuesta a explicar por qué esa noticia es sensacionalista o errónea o una basura. Si no suben esas noticias a portada nunca leeré los comentarios y cuando las vea en otros medios me la meterán doblada. Eso sin contar que la vara que se usa para medir si una noticia es sensacionalista (o lo que sea) es por ser suave, cuestioble. A veces llegan noticias a portada que son una basura (noticias sobre las que entiendo) y otras veces no llegan buenas noticias porque a alguien sin ni idea del tema le parece que no son "dignas" de portada...

    En resumen, déjame leer las noticias, déjame leer los comentarios y ya me formaré yo mi propia opinión de si esa noticia es basura o no.

    Pero bueno, como digo, esta solo es mi opinión.
  67. #175 yo intento meterme lo menos posible en votar cosas polémicas, sobre todo si no conozco mucho del tema.

    Y sí, sé que puede que sea la excepción pero eso no significa que los votos negativos sean inútiles.
  68. #9 En efecto, ahora se intena meter en todas partes, aunque sea para montar un blog.
  69. #28 {0x1f602} {0x1f602} {0x1f602} {0x1f602} {0x1f602} {0x1f602} Y si le añades el Multus y el Istio te sale la gráfica de K8S a deber {0x1f61b}
  70. #39 #40

    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.
  71. #59 sin problema. sigo teniendo razón ;)
  72. #16 ¿Eso no lo debería hacer el Sysadmin? ¿O con el cuento de devops y agile (todos somos t-shaped bitches) te toca comerte el marrón? Para las empresas pequeñas, con el personal Justino, pasa lo que en esta tira:  media
  73. #22 no es tan sencillo de explicar, yo diria que docker es mas para clusters, para un servidor sin mas, puedes usar docker en produccion, aunque supongo que no es lo mismo.

    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.
  74. #43 mierda, esto era para #16
  75. #89
    > 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.
  76. Sirve para contener la mierda de otros a buen recaudo. Osea, paquetizas los desarrollos para que no "choquen" con los nuevos desarrollos. Terminas con 300 microservicios y arde el mundo, el cielo y tu p**a cabeza, eso si, mas facil que contener dicha cantidad de basura de desarrollos en una o varias máquinas virtuales.
    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á.
  77. #48 pues pregunta y te aclaro si quieres. :-)
  78. #25 ¿y si tienes un entorno en el que tienes que levantar muchos servicios pequeños, cómo haces? ¿Los metes todos sobre hierro en un totum revolutum dentro del mismo sistema operativo, los metes en máquinas virtuales desperdiciando recursos...? Pregunto por saber. A lo mejor me dices algo que me sorprende o en lo que no he caído. Lo digo sin ironía.
  79. #77 #76
    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.
  80. #102 Pues depende mucho de tus necesidades y lo que ya tengas ya montado si montas una startup en la que empiezas desde 0 y contratas a 4 sysadmins con experiencia en kubernetes que te montan un cluster productivo en un momento.

    Si tienes montado una suite de virtualización como pueda ser vmWare u oVrit que conoces como dios, y tienes a gente que pilota la ostia de Apache y tienes una docena de aplicaciones monolíticas que despliegan de pascuas a ramos, seguramente te convenga más quedarte como estás.

    Yo diría que para tener un kubernetes bien montado y productivo necesitas mínimo 3 o 4 sysadmins dedicados a ello. Si para gestionar las aplicaciones y despliegues necesitas un 5º ya te empieza a interesar kubernetes.

    Kubernetes por otro lado gestiona bastante mal cierto tipo de cargas, por ejemplo las bases de datos salvo que hayan sido especificamente diseñadas para ejecutarse en un entorno volátil, no es meter tu aplicación en un contenedor y a correr, si tienes un volumen grande de aplicaciones que no gestionan bien las paradas (recordemos que en kubernetes no hay live migration) a lo mejor tiene más sentido un openstack o incluso tirar de un IaaS público.
  81. #162 Hay que decir que OpenStack es muchísimo más complejo y muchísimo más potente. Antes de trabajar con kubernetes trabajé desarrollando una de OpenStack.

    Respecto a usar un kubernetes gestionado si encuentras un buen kubernetes gestionado es buena opción, tengo entendido que Red Hat vende OpenShift gestionado, en instalaciones on premise seguramente sean los que más éxito tienen así que imagino que el gestionado no irá mal tampoco. También lo vende amazon y google cloud aunque no los he probado. El de azure dicen que va bastante bien aunque yo me llevé mala impresión cuando lo probé (eso si, acababa de salir, y SEGURO uqe ha mejorado, no se si
  82. #183 el primer párrafo no lo entiendo y lo de "está claro que crees que el presente es puramente contenedor" es sencillamente absurdo, además de falso.

    Lo que sí tengo claro es que no has trabajado profesionalmente en esto por lo que dices, y si lo has hecho habrá sido en cosas muy pequeñas.
  83. si es como gnu es asqueroso
  84. #100 Perdona ?????
    Tu no usas git en una consola????
    Parece que no, cuando dices que hay que escribir los hash a mano.
    Esta claro que nivel muy alto no trabajas cuando dices semenjante cosas, pues precisamente la forma mas rapida de desplegar codigo , en un contener es una instancia es precisamente con docker , una consola y todos los beneficios de trabajar en una consola.
  85. #131 ¿por qué comparas una máquina virtual con "varios cientos" de contenedores"? Lo que haces con una máquina virtual lo puedes hacer con un solo contenedor, pero con muchas ventajas, como consumir muchos menos recursos.
  86. #133 ¿se puede saber qué ganas utilizando chroot en lugar de un contenedor?
  87. #136 Swarm no lo he utilizado, pero tiene buena pinta. Creo que es lo que yo utilizaría.
  88. #137 es cierto que la palabra es incorrecta, pero no me parece tan grave. Los conceptos en informática son complicados y difusos y este artículo está pensado para profanos en el tema.
  89. #138 ¿a qué párrafo te refieres?
  90. #141 no lo he probado, pero como concepto es ideal para cosas pequeñas. Kubernetes para algo pequeño me parece muy excesivo.
  91. #145 Traefik es un proxy inverso por lo que he leído.

    Eso que dices está bien para cosas pequeñas. Si tienes un clúster como el de un banco lo que haces puede ser difícil de gestionar. Kubernetes es más adecuado.
  92. #150 no estoy discutiendo, no te pongas tenso. Solo que no encuentro sentido a lo que dices por el momento. Puede que lo esté entendiendo mal o puede que te expliques mal.

    ¿Por qué un contenedor para cada página es un absurdo y una máquina virtual para cada página (es lo que entiendo que propones, aunque no lo entiendo del todo) no lo es?
  93. #152 ¿y vas a meter "cientos" de páginas web en una sola máquina virtual? ¿En serio? :-)
  94. #153 es obvio que para tres servidores es absurdo tener Kubernetes. No está pensado para eso, de hecho.

    Lo que tienes no me parece mala opción, salvo dos puntos aparentemente: el balanceo por DNS puede ser problemático y no sé qué tolerancia a fallos tienes. Esto último lo solucionarías con algo como Swarm, aunque nunca lo he probado.
  95. #156 ¿y te parece un buen diseño tener una máquina virtual con cien servicios de forma que si la máquina se cae se te caen los cien?
«12
comentarios cerrados

menéame