|
pram posted:containers and their schedulers aren't anything new. openvz and zones and yarn etc have been around forever. it's just docker made the build and image management part very easy. IRL deployment is still a major pain though unless your app is totally stateless/doesn't need any local persistence docker succeeded because it made the single developer experience super simple. it failed miserably at build for years until it introduced image flattening and its image management is super dumb by default for having any form of consistency throughout your deployments
|
# ? Jun 9, 2017 20:20 |
|
|
# ? May 28, 2024 15:59 |
|
i want to make a personal website. what container / cloud should i use ??
|
# ? Jun 10, 2017 22:01 |
|
geocities
|
# ? Jun 10, 2017 22:06 |
|
⚰️
|
# ? Jun 10, 2017 22:13 |
|
Shinku ABOOKEN posted:i want to make a personal website. what container / cloud should i use ?? digitalocean
|
# ? Jun 10, 2017 22:59 |
|
pram posted:digitalocean digitalocean is good, my monitoring server is hosted there
|
# ? Jun 11, 2017 00:21 |
|
Silver Alicorn posted:I still don't get what the gently caress containers are supposed to do same, honestly. i'm sure it's just lack of exposure on my part but the way people i know talk about docker it sounds like they're trying to shoehorn some kind of build artifact into their interpreted languages.
|
# ? Jun 11, 2017 07:11 |
|
well if you've literally never set up a server to host an app, probably you won't understand because that's what it's for
|
# ? Jun 11, 2017 07:48 |
|
Historically containers are basically the product of several kernel level features that provide both process isolation and resource management for one or more processes that have been grouped together. In essence a container is a "really fancy chroot" that is more analogous to virtual memory than traditionally understood virtual machines. Processes in a container usually have at least an additional layer of virtualizated memory, CPU priority, network devices and their own restricted view of the file system. One of the biggest use cases for this were things like VPS products. Prior to time that hosting providers like AWS and Linode appeared, if you had any kind of dedicated server that didn't cost thousands a month your dedicated server was probably actually a container. Containers were far more popular with hosting providers mostly for economic reasons. You can oversell containers on a single physical server a lot more than you can hardware VMs. They are also a lot easier to manage and secure since it is impossible to be locked out of them. From the hosting providers point of view all the processes running on your server are just one of many groups of processes running on their servers operating system. Now with Docker you have a platform that is using the same kind of underlying kernel features for process grouping and isolation, but instead of using them to make virtual servers they are used to make a very generalized application server with a bunch of user space tools for application deployment and management. I'm surprised I haven't head more parallels drawn to "Write once, run anywhere" promise of the JVM. Essentially Docker offers you the same thing but in any language. Once your app is packaged up as a docker container it can be deployed anywhere that is running docker and """should""" function identically.
|
# ? Jun 11, 2017 08:42 |
|
NeoHentaiMaster posted:a very generalized application server I'm glad to hear somebody else describe Docker this way. I've been thinking of Docker as kind of an intermediate technology between VMs and application servers for ages, but I could never figure out why nobody else did and whether there was something I was missing. Does "Write once, run anywhere" still come with the caveat "as long as it's 64-bit Linux"?
|
# ? Jun 11, 2017 13:53 |
|
Basically yes
|
# ? Jun 11, 2017 15:56 |
|
you can install docker on windows but it's an Ubuntu vm iirc
|
# ? Jun 11, 2017 15:57 |
|
Doom Mathematic posted:Does "Write once, run anywhere" still come with the caveat "as long as it's 64-bit Linux"? well more importantly, write once run anywhere doesn't actually work anywhere else that promises it and the caveat is 'with whatever architecture you built the container with' but lmbo if you're running production that isn't 64-bit linux
|
# ? Jun 11, 2017 16:25 |
|
Here is what is cool and good about containers: it forces developers to actually state their loving requirements and put all that poo poo together so I don't have to janitor their special snowflakes, while keeping their stupid fingers far away from the infrastructure. Here is what sucks about containers: everything else.
|
# ? Jun 11, 2017 21:12 |
|
Visual GNUdio posted:Here is what is cool and good about containers: it forces developers to actually state their loving requirements and put all that poo poo together so I don't have to janitor their special snowflakes, while keeping their stupid fingers far away from the infrastructure. mega
|
# ? Jun 11, 2017 22:13 |
|
update: i don't want to get into containers anymore, now i'm trying to learn chef you are free to continue containerchat at your leisure
|
# ? Jun 11, 2017 23:42 |
|
learn ansible instead
|
# ? Jun 11, 2017 23:51 |
|
RISCy Business posted:now i'm trying to learn chef lol, i almost had to learn that once
|
# ? Jun 12, 2017 01:06 |
|
Ansible is useful for remote command execution and orchestration. If you're using it as a configuration management framework for more than a dozen machines you are a FOOL.
|
# ? Jun 12, 2017 01:07 |
|
NeoHentaiMaster posted:Ansible is useful for remote command execution and orchestration. If you're using it as a configuration management framework for more than a dozen machines you are a FOOL. Right and that is the point where you should run mesos or kubernantes. (if anyone has questions on either I've used both.)
|
# ? Jun 12, 2017 02:43 |
|
NeoHentaiMaster posted:Ansible is useful for remote command execution and orchestration. If you're using it as a configuration management framework for more than a dozen machines you are a FOOL. why
|
# ? Jun 12, 2017 02:49 |
|
con-tayne-rs
|
# ? Jun 12, 2017 03:18 |
|
pushing yaml files from arbitrary locations doesn't scale on both infrastructural and organizational levels.
|
# ? Jun 12, 2017 04:12 |
|
it's literally possible to have a git repo with all your playbooks same way you can have a git repo that has all your puppet modules
|
# ? Jun 12, 2017 04:15 |
|
|
# ? May 28, 2024 15:59 |
|
and lol at chef and puppet 'scaling' organizationally at all. ive seen zero good deployments in 3 giant corporations. it's always a giant pile of poo poo with ridiculous edge cases. did they use hiera? are they depending on some bizarre facter bootstrap to work? are they using roles or is everything hardcoded in the module? do you need to create ten dozen different node files for it to work? are they using some kind of in house enc? did they use LWRP, or libraries, or HWRP? has everything become a custom rube goldberg machine written directly in ruby?? do you need to refactor this dumpster fire to get anything done? yes
|
# ? Jun 12, 2017 04:22 |