It's not overkill. Provision a VPS host with docker, create single haproxy container with configuration and you can put any number of applications behind it. it will take you 2 hours two automate from VPS with ssh to full host, two days if you have never done ansible before and you can migrate it within minutes anywhere at any time. It's actually how you should do "just some websites" hosting.
I'm just frustrated because I've never done any of this before, and all I can see is time ticking away. I know, ultimately, that I need to learn how to do this, I just wish it was a little more straightforward (I haven't found much in the way of "This is how you do what you (me, specifically) want to do" tutorials out there).
I already have a linode instance. I'm sure I can install Docker on it myself. It's just the extra layer(s) of configuration I'm not looking forward to.
More frustration: what the hell is ansible?
Ansible, Chef and Puppet are Infrastructure as Code tools for automating server maintenance and stand up.
Better, but I still wish it cleaned up the empty lines around the Println too.
It feels like I could just replace every instance of 'blank line, then }' with just '}', and every instance of '{, then blank line' with just '{', but I'm not 100% sure. I guess once I've got latest code committed I can always try it and see.
I think what I'm going to do is deploy her site the old way, because the clock is ticking and I can't rightfully delay it the amount of time it would take to learn/test/refactor new technology/techniques. But, once it's deployed, I'll focus on modernizing my workflow, because I'm hurting myself long term not knowing/doing it.
you need to fire an event for the following in meaningful use:
query (lookup of a patient's medications, problems, histories, demographics, vaccinations, etc etc etc etc)
addition
deletion
editing
printing
In order to capture it, the recommended way is MySQL triggers. So if for some reason your triggers fuck up, congratafuckulations, you're no longer compliant with meaningful use.
I'm making a lot more work for myself, but I moved it to the REST stuff.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
The trick with databases is to remember that below about a billion rows you probably aren't actually taxing the database in any way that matters on modern hardware, doubly so if queries are infrequent.
Which is why next week's task is going to be modifying the PowerDNS API to have a shim which just records and logs every single mutation, so we can step forward/backwards through what people have done.
I dunno, adding ~30,000 records a day to an audit log seems ridiculous for 20 some odd employees.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
So for more "Extol the virtues of application virtualization, docker in particular":
After running in to a whole slew of issues across two VPS's running a docker swarm node in Debian 8.8/Linux 3.16, I decided I wanted to try a bit more up to date OS and kernel. I could have gone with Debian Stretch, but I decided on Ubuntu 17.04 instead because it's released/supported software, uses Linux Kernel 4.10 and is based on Debian which is the Linux distro I know best.
My VPS doesn't offer 17.04 so I had to go from 16.04 to 17.04 via do-release-upgrade, which took about 45 minutes. From the time that finished, so a raw Ubuntu 17.04 box, I had Docker installed, my load balancer and two of my stacks running including databases, private docker networks, etc, up and working, with full SSL on my two sites, in 10 minutes.
I swear PG Admin gets slower and slower for each update.
The v4 rewrite is a damned monstrosity. It smacks of "if we use web-technologies it'll run everywhere" and then everyone shook hands and smiled a lot and forgot that apps written like that tend to be super shitty unless you put a metric asston of work into them.
I swear PG Admin gets slower and slower for each update.
The v4 rewrite is a damned monstrosity. It smacks of "if we use web-technologies it'll run everywhere" and then everyone shook hands and smiled a lot and forgot that apps written like that tend to be super shitty unless you put a metric asston of work into them.
Atom and Visual Studio Code are both written in web technology, both being based on Electron, and both work fine. It's actually pretty easy to do if you think about your app a certain way (e.g. like a browser connected to a server, only the connection is IPC and the latency is effectively 0).
Does Docker have its own repo? I'm guessing it does, since a lot of the examples I've seen start with FROM <some Linux distro> which makes me think that it's magically getting the base OS/environment you tell it to use from a central source.
Does Docker have its own repo? I'm guessing it does, since a lot of the examples I've seen start with FROM <some Linux distro> which makes me think that it's magically getting the base OS/environment you tell it to use from a central source.
You mean https://hub.docker.com/. Docker uses repositories called "A docker registry". The centralized one is the dockerhub, whenever you see something referenced in a Dockerfile, most of the time it will be pulling an image pushed to the hub.
I swear PG Admin gets slower and slower for each update.
The v4 rewrite is a damned monstrosity. It smacks of "if we use web-technologies it'll run everywhere" and then everyone shook hands and smiled a lot and forgot that apps written like that tend to be super shitty unless you put a metric asston of work into them.
Atom and Visual Studio Code are both written in web technology, both being based on Electron, and both work fine. It's actually pretty easy to do if you think about your app a certain way (e.g. like a browser connected to a server, only the connection is IPC and the latency is effectively 0).
I thought "unless you put a metric asston of work into them" would've covered products like Atom and VS Code.
The appeal of Go to me is really how I can make a single Git repo and then vendor in the libraries for all its dependencies + the linters and support tools necessary to build and quality check it, and link all that to a makefile which knows how to update the whole lot.
Which means a single Git clone pulls down everything you need to build the project.
And what really weirds me out is watching colleagues go to ridiculous lengths to try and setup a tenuous network link to the whole affair, so that something downloads from somewhere we don't control but then is *exactly* the commitish or version or whatever that it should be.
ah man.... that feeling when all 30 migrations piling up over the last few weeks all run in production without a hitch... *edit* spoke too soon! well shit *edit* not migration related at all. all good! the trials and tribulations of part time server administration
The appeal of Go to me is really how I can make a single Git repo and then vendor in the libraries for all its dependencies + the linters and support tools necessary to build and quality check it, and link all that to a makefile which knows how to update the whole lot.
Which means a single Git clone pulls down everything you need to build the project.
And what really weirds me out is watching colleagues go to ridiculous lengths to try and setup a tenuous network link to the whole affair, so that something downloads from somewhere we don't control but then is *exactly* the commitish or version or whatever that it should be.
Java (and Scala) programmers are weird.
Yeah, that's how we do the repos for our stuff that runs as Docker containers. Make your changes, do a "godeps save ./..." and commit that, and it's all contained in the repo. Push button, get build.
The appeal of Go to me is really how I can make a single Git repo and then vendor in the libraries for all its dependencies + the linters and support tools necessary to build and quality check it, and link all that to a makefile which knows how to update the whole lot.
Which means a single Git clone pulls down everything you need to build the project.
And what really weirds me out is watching colleagues go to ridiculous lengths to try and setup a tenuous network link to the whole affair, so that something downloads from somewhere we don't control but then is *exactly* the commitish or version or whatever that it should be.
Java (and Scala) programmers are weird.
What would happen if your project had around 100mb of dependencies? Would you really want all that inside your git repo?
And if you had 10 projects with the same dependencies, would you want to duplicate them inside each repo, rather than store them in one location for each project to access?
Another question in my attempt to wrap my head around Docker:
So, the custom images start with a base image. From what I've seen, that's usually a linux distro. If I were to do a system setup like (I believe) Infidel suggested earlier with:
1 container for a reverse proxy
1 container for a database
1 + n containers, with each being its own web app that the proxy forwards requests to
Would that mean that each of those would be based on a separate linux distro image? Or would they share a single OS through Compose? And if they're not shared, then how is that slimmer than running multiple VMs?
My copy doesn't seem to be that ... enthusiastic, but yeah. It hovers at ~5% doing god knows what (like, not even connected to a PG server; just sitting at the default window it opens up to). :rotate:
Another question in my attempt to wrap my head around Docker:
So, the custom images start with a base image. From what I've seen, that's usually a linux distro. If I were to do a system setup like (I believe) Infidel suggested earlier with:
1 container for a reverse proxy
1 container for a database
1 + n containers, with each being its own web app that the proxy forwards requests to
Would that mean that each of those would be based on a separate linux distro image? Or would they share a single OS through Compose? And if they're not shared, then how is that slimmer than running multiple VMs?
Depends on exactly what you need, but in terms of general efficiency, you would base the images for each of those things on the same base. All layers which are the same across images are stored only once by docker. Then what you run is a container, you can run multiple containers based off of the same image (such as for your actual web app) and again that only has to store one copy of the image.
Think of image -> container being along the lines of class -> instance.
I'm going to just make up numbers here for examples. Just looking at the disk space side of thing because that's the part I understand best. So you can have say, a base Ubuntu image which is 300MB. Then you have your nginx proxy image based on that ubuntu image. Now since it is based on the Ubuntu image and just has nginx installed. Both images combined are only taking up 350MB - it's reusing the matched layers from the base ubuntu image, think of it like OO class inheritance. Now you make an image for your web app also based on the 300MB ubuntu image. Your web app adds 50MB to it - so now your docker images take up 400MB total. Now you fire up one nginx container and one web app container - you're still only using about (each instance running is going to use some disk space) 400MB of disk space. Fire up 5 more web app containers - the same base image is used, you're still only using about 400MB of disk space.
Memory and CPU usage wise it's also similar because it's not a full blown VM that you're running. I actually do not have a good enough grasp of it to explain it beyond that it is much lighter weight because it is not virtualizing an entire CPU.
Compare that to doing the same thing with a traditional VM. Scrap the base ubuntu because VMs don't do inheritance like that. So you've got a 350MB image for nginx. Another 350 image PER web app instance you want to run. That adds up quick. You are also virtualizing a full computer, it's hardware, etc. per thing you are running, using up way more CPU and memory on your host.
That was a pretty great explanation of Docker. I knew there was some resource sharing things going on with images but never really looked into it.
It's CoW sharing of fs layers. It's also one of the reasons you generally strive to balance # of layers with sharing of said layers.
Edit: It's also still one of the buggiest parts of the docker world, while stability has improved drastically, docker is still fully able to kill your disk usage on long running containers.
Memory and CPU usage wise it's also similar because it's not a full blown VM that you're running. I actually do not have a good enough grasp of it to explain it beyond that it is much lighter weight because it is not virtualizing an entire CPU.
A good way to explain it is by focusing on Docker as a method of process isolation instead of resource dedication.
I've looked at the docker website myself and it's sorely lacking some "here's the super basic basics" explanations like this, or at least I couldn't find one -- how does Docker handle network stuff? If I have nginx running in a VM, then I can tell my VMware instance to connect up ports between the VMs, so is there an equivalent for docker to say "port 80 coming into my machine goes to 'docker-instance-nginx'? (and if there was, why would I have a reverse proxy running in one instance rather than using docker config to redirect ports like this?)
Posts
Ansible, Chef and Puppet are Infrastructure as Code tools for automating server maintenance and stand up.
It feels like I could just replace every instance of 'blank line, then }' with just '}', and every instance of '{, then blank line' with just '{', but I'm not 100% sure. I guess once I've got latest code committed I can always try it and see.
well, huh... where do I start....
Which came first, the app or the os?
These are the kinds of mysteries we may never know
I mean, not literally, but it feels like it sometimes.
there's no meaningful way to look through it
Sounds like you need some Big Data(tm) in your life, son!
The stuff that shouldn't be meaningful pretends like it is.
The whole audit log thing blows my mind, there's just so much data there that you will never be able to effectively query it.
query (lookup of a patient's medications, problems, histories, demographics, vaccinations, etc etc etc etc)
addition
deletion
editing
printing
In order to capture it, the recommended way is MySQL triggers. So if for some reason your triggers fuck up, congratafuckulations, you're no longer compliant with meaningful use.
I'm making a lot more work for myself, but I moved it to the REST stuff.
Which is why next week's task is going to be modifying the PowerDNS API to have a shim which just records and logs every single mutation, so we can step forward/backwards through what people have done.
After running in to a whole slew of issues across two VPS's running a docker swarm node in Debian 8.8/Linux 3.16, I decided I wanted to try a bit more up to date OS and kernel. I could have gone with Debian Stretch, but I decided on Ubuntu 17.04 instead because it's released/supported software, uses Linux Kernel 4.10 and is based on Debian which is the Linux distro I know best.
My VPS doesn't offer 17.04 so I had to go from 16.04 to 17.04 via do-release-upgrade, which took about 45 minutes. From the time that finished, so a raw Ubuntu 17.04 box, I had Docker installed, my load balancer and two of my stacks running including databases, private docker networks, etc, up and working, with full SSL on my two sites, in 10 minutes.
The v4 rewrite is a damned monstrosity. It smacks of "if we use web-technologies it'll run everywhere" and then everyone shook hands and smiled a lot and forgot that apps written like that tend to be super shitty unless you put a metric asston of work into them.
Debugging CUDA code is mildly interesting. Debugging 20,000 lines of CUDA code all in a single file. Not so interesting.
Atom and Visual Studio Code are both written in web technology, both being based on Electron, and both work fine. It's actually pretty easy to do if you think about your app a certain way (e.g. like a browser connected to a server, only the connection is IPC and the latency is effectively 0).
Does Docker have its own repo? I'm guessing it does, since a lot of the examples I've seen start with FROM <some Linux distro> which makes me think that it's magically getting the base OS/environment you tell it to use from a central source.
Start in these two places:
https://github.com/moby/moby
https://github.com/docker/distribution
I thought "unless you put a metric asston of work into them" would've covered products like Atom and VS Code.
Which means a single Git clone pulls down everything you need to build the project.
And what really weirds me out is watching colleagues go to ridiculous lengths to try and setup a tenuous network link to the whole affair, so that something downloads from somewhere we don't control but then is *exactly* the commitish or version or whatever that it should be.
Java (and Scala) programmers are weird.
Yeah, that's how we do the repos for our stuff that runs as Docker containers. Make your changes, do a "godeps save ./..." and commit that, and it's all contained in the repo. Push button, get build.
What would happen if your project had around 100mb of dependencies? Would you really want all that inside your git repo?
And if you had 10 projects with the same dependencies, would you want to duplicate them inside each repo, rather than store them in one location for each project to access?
So, the custom images start with a base image. From what I've seen, that's usually a linux distro. If I were to do a system setup like (I believe) Infidel suggested earlier with:
1 container for a reverse proxy
1 container for a database
1 + n containers, with each being its own web app that the proxy forwards requests to
Would that mean that each of those would be based on a separate linux distro image? Or would they share a single OS through Compose? And if they're not shared, then how is that slimmer than running multiple VMs?
Depends on exactly what you need, but in terms of general efficiency, you would base the images for each of those things on the same base. All layers which are the same across images are stored only once by docker. Then what you run is a container, you can run multiple containers based off of the same image (such as for your actual web app) and again that only has to store one copy of the image.
Think of image -> container being along the lines of class -> instance.
I'm going to just make up numbers here for examples. Just looking at the disk space side of thing because that's the part I understand best. So you can have say, a base Ubuntu image which is 300MB. Then you have your nginx proxy image based on that ubuntu image. Now since it is based on the Ubuntu image and just has nginx installed. Both images combined are only taking up 350MB - it's reusing the matched layers from the base ubuntu image, think of it like OO class inheritance. Now you make an image for your web app also based on the 300MB ubuntu image. Your web app adds 50MB to it - so now your docker images take up 400MB total. Now you fire up one nginx container and one web app container - you're still only using about (each instance running is going to use some disk space) 400MB of disk space. Fire up 5 more web app containers - the same base image is used, you're still only using about 400MB of disk space.
Memory and CPU usage wise it's also similar because it's not a full blown VM that you're running. I actually do not have a good enough grasp of it to explain it beyond that it is much lighter weight because it is not virtualizing an entire CPU.
Compare that to doing the same thing with a traditional VM. Scrap the base ubuntu because VMs don't do inheritance like that. So you've got a 350MB image for nginx. Another 350 image PER web app instance you want to run. That adds up quick. You are also virtualizing a full computer, it's hardware, etc. per thing you are running, using up way more CPU and memory on your host.
It's CoW sharing of fs layers. It's also one of the reasons you generally strive to balance # of layers with sharing of said layers.
Edit: It's also still one of the buggiest parts of the docker world, while stability has improved drastically, docker is still fully able to kill your disk usage on long running containers.
A good way to explain it is by focusing on Docker as a method of process isolation instead of resource dedication.