71–80 of 123 posts
I work on Cloud Foundry buildpacks, several of which are downstream from Heroku's. So I'm professionally interested in seeing another perspective on how to drive them.
Earlier quoted context omitted.
Yeah I really would be cautious, I just did the reverse (Flynn -> dokku), and found that even after re-deploying a few images on Flynn it wasn't cleaning up images and disk space was disappearing fast (was hitting my 20GB linode limit without having half of my apps deployed). So I ended up giving dokku a shot and that thing is lean in comparison, I was able to setup all my apps (about 7 of them) including redeploying…
> re-deploying a few images on Flynn it wasn't cleaning up images and disk space was disappearing fast I'm really sorry to hear that you switched off of Flynn. We're aware of this issue, and are in the process of fixing several things that can cause it (it only happens when not using an external blobstore backend like S3). Hopefully you'll try Flynn again at some point in the future!
You can do HIPAA on AWS yourself or use (expensive vendors). However both of these routes lose you the management/deployment abilities of things like Heroku/Flynn.
Since there are some Flynnsters hereabouts: do you run buildpacks unmodified? How do you deal with fully disconnected environments? I work on Cloud Foundry buildpacks, several of which are downstream from Heroku's. So I'm professionally interested in seeing another perspective on how to drive them.
So far no one is using Flynn in a fully disconnected environment, and we're aware of this limitation. My take on this is that we need a replacement for buildpacks that allows for repeatable/functional builds (think Nix for app deployment).
Flynn and deis definitely seem interesting, as does the tooling that coreos and docker themselves are working on.
Earlier quoted context omitted.
I'd also back dokku for small side projects. I have 4 small slack bots installed on my reserved t2micro instance and I'm pretty happy with it.
Ah, if only people backed Dokku monetarily[1]. I'd probably get my ass in gear and release the multi-server functionality I prototyped over the summer. Nice to see that others are finding Flynn useful though, there is plenty of space for PaaS offerings, and I truly hope they are financially successful. [1] My experience in this area is that it's hard to get peple to pay for something that is free, which dis-incentivi…
Earlier quoted context omitted.
I'd also back dokku for small side projects. I have 4 small slack bots installed on my reserved t2micro instance and I'm pretty happy with it.
Ah, if only people backed Dokku monetarily[1]. I'd probably get my ass in gear and release the multi-server functionality I prototyped over the summer. Nice to see that others are finding Flynn useful though, there is plenty of space for PaaS offerings, and I truly hope they are financially successful. [1] My experience in this area is that it's hard to get peple to pay for something that is free, which dis-incentivi…
Is there any HIPAA story for Flynn? You can do HIPAA on AWS yourself or use (expensive vendors). However both of these routes lose you the management/deployment abilities of things like Heroku/Flynn.
Compliance is a really interesting vertical. As we make progress on our security roadmap, Flynn will become a very compelling option for environments like HIPAA, PCI, etc. especially when combined with clouds like AWS that are also compliant.
Since there are some Flynnsters hereabouts: do you run buildpacks unmodified? How do you deal with fully disconnected environments? I work on Cloud Foundry buildpacks, several of which are downstream from Heroku's. So I'm professionally interested in seeing another perspective on how to drive them.
Yeah, we ship unmodified Heroku buildpacks, plus one Cloud Foundry buildpack ( https://github.com/cloudfoundry/staticfile-buildpack ). So far no one is using Flynn in a fully disconnected environment, and we're aware of this limitation. My take on this is that we need a replacement for buildpacks that allows for repeatable/functional builds (think Nix for app deployment).
One gotcha: if you are snapshotting images after building, your images are not truly reproducible. Heroku occasionally swap out the binaries. This surprised once or twice. This is one reason we wound up building all our own runtime binaries[1].
When you get to disconnected environments, look us up. We built a whole tooling, compile-extensions[2], to make it pretty close to seamless. We intercept URLs and transform their either into our URLs or local copies of the files.
(edit: actually, you could just switch to the Cloud Foundry buildpacks, since they have an identical detect/compile/release cycle)
I agree that buildpacks are not the super long term solution. One area being explored by engineers at Pivotal and IBM is to give a buildpack-like experience to OCI layers[3]. I'm sure they'd be happy to work with you on this as well.
[1] https://github.com/cloudfoundry/binary-builder [2] https://github.com/cloudfoundry/compile-extensions [3] https://www.youtube.com/watch?v=DSTT0przx4g&list=PLhuMOCWn4P...
Is there any HIPAA story for Flynn? You can do HIPAA on AWS yourself or use (expensive vendors). However both of these routes lose you the management/deployment abilities of things like Heroku/Flynn.
The docker security sandbox has had a few issues, and probably should not run sensitive data for multiple partners on the same ec2 instance. ymmv though.