I used to use Anvil (through hammer) to build some native libs to be bundled with a rails app. Specifically I was building libapngasm using this:
https://github.com/Kagetsuki/heroku-buildpack-apngasm
Unfortunately it seems Anvil has been discontinued and I couldn't find any information on how to do a remote build and retrieve the resulting binaries through the Build API.
Is there a new alternative to Anvil? What is a "correct" way to do this?
OK, the official answer here was a little more obvious than I had expected. Basically if you're running the same gcc/libc~ as that stack your dyno is running compile locally. Otherwise just spin up a VM or a docker image with a compatible version and build on that. Then just vendorize the libraries/binaries into your app repository so they'll be bundled up with the slug when you push. Finally, set your heroku environment load path to find the libs/bins you bundled.
Related
I'm considering building app with Django for only one user that would run application locally on windows. I read about containerizing Django apps, but it's new for me.
My goal is to run Django server on one click like a standard windows app and connect to it on localhost and interact with web browser. It is even possible?
It is possible, but this may not be the best solution. If you want to release a Django app that can be installed on your client computer, you usually need to ensure all the dependencies are shipped with the app.
Containerising your application means it will depends on Docker runtime (or any container system you use). You will have to setup Docker with your app, or ensure your client has Docker on his machine to run it. If the destination machine runs Windows or macOS, you will need to setup docker-desktop which may be more complicated than standard Docker runtime (linux only).
But if you decide to ship your app without containerising it, it will only depends on a Python interpreter and some dependencies (Django, dateutil, etc.). In such case, using python tools like virtualenv, you may prepare a ready-to-run application by creating the venv and installing dependencies at "build time". Then, with a proper setup (MSI for Windows or DMG for macOS), you may be able to distribute the final application so the client can install and run it without any additional step (you do all the hard job yourself).
Django app can be convert into .exe but it wont work as local server while click .exe because runserver command and some of django service wont support on this way as per my experiment.
The apt-buildpack is experimental and not yet intended for production use. I guess that's why also no documentation.
Creating container
Successfully created container
Downloading app package...
Downloaded app package (862.7K)
Warning: this buildpack can only be run as a supply buildpack, it can not be run alone
Failed to compile droplet: Failed to compile droplet: exit status 1
Destroying container
Exit status 223
Stopping instance abdfc8d0-699e-4834-9f2d-2b8aec218423
Successfully destroyed container
Can you give me example how to push cf-env sample app and install for example rtorrent and/or openvpn. Is it possible to install gnome for testing purposes?
As far as usage goes it's pretty simple, you just need to include an apt.yml in the root directory of your app. That should contain among other things, the list of packages to install.
Ex:
---
packages:
- ascii
- libxml
- https://example.com/exciting.deb
The buildpack supports installing package names, deb files, custom APT repositories, and even PPAs.
Please see the README for further instructions.
This message:
Warning: this buildpack can only be run as a supply buildpack, it can not be run alone
Is telling you that the Apt buildpack only functions to supply binaries. It doesn't actually know how to run your app or any application. For more on the supply script, check out the docs here.
The trick to making it work is that you need to use multi buildpack support. Instructions for doing that can be found here. This should work with most apps, but there's a simple example here.
Once your app stages & starts, you can confirm that your packages were installed by running cf ssh apt-test -t -c "/tmp/lifecycle/launcher /home/vcap/app bash ''". Anything that was installed should be on the path, but if you want to see where things are installed it'll be under the /home/vcap/deps/<buildpack-number>/.
That should be about it. Hope that helps!
I am deploying a React app on AWS Elastic Beanstalk. I bundle the app using webpack. However, I'm slightly confused about what best practices are from the production build process. Should I build the app locally (with NODE_ENV=production) using webpack, and then just upload the resultant bundle.js file, along with all node_modules to the Elasticbeanstalk instance? Or, should I upload all the source files, and run webpack on the actual cloud AWS server during deployment?
You should never build for production locally (unless you're the only developer).
Ideally, you have a build process that gets triggered manually or automatically from a git commit which then builds your project for production for you.
By using a centralized build process, you can then be sure that all your builds are built the same way (e.g. same node version, same npm or yarn version).
Both approaches are not really good to be honest. Local building is not a best way to build anything you want to have on production. You might have packages locally that may have inpact on what you're building. Same applies to the OS your doing it on.
And, again, same applies to the building during deployment. As the name of 'deployments' stands for, it's deploying. Just placing your application setup on the server so it may serve as it is supposed to.
That's the point where all CI/CD comes in. Having those kinds of solutions guarantee that each build is done with the same steps and on the same solution stack. No difference between each build is desired, because it allows you to assume that any bug or a change comparing to the 'desing' is because of the code, not environment it was build within.
Assuming that you're the only developer here (because you're asking for such a thing), CI/CD might be definitive overkill here, so just create shell script with steps and use Docker as the environment for build, so it stays the same between each build. That's the closest to the CI/CD option you can get without a hassle.
We're using the hosted build agent on VSTS to build and release our ASP.NET Core code to Azure App service.
My question is: can we run WebPack to handle front-end tasks on this hosted build on VSTS or do we have to do it manually before checking the code into our repository?
Update:
I'm utilizing the new ASP.NET Core Build (Preview) template that's available on VSTS -- see below:
Here are the steps -- out of the box:
For VSTS we're working on an extension, currently it's in beta phase, you can ask for a share.
Check the VSTS marketplace.
Check this github repo.
Webpack is definitively not a first class citizen for VS2015 and VSTS. Streamlining webpack for CI/CD has been a real headache in my case, especially as webpack was introduced hastily to solve dreadful performance issues with a large monolithic SPA (ASP.NET 4.6, Kendo, 15,000 files, 2000 folders). To cut short, after trying many scenarios to make sure that freshly rebuilt bundles would end up in IIS and Azure webapp, I did a 2-pass build. The sequence of VSTS tasks is as follows: npm install global, npm install local, npm webpack install local, npm webpack install global, build pass 1, webpack, build pass 2, etc... This works with hosted and private agents, providing you supply the proper path for webpack as webpack is installed in a different location in host and in private (did not find a way to chose the webpack install location for consistency). I scorch everything before starting the build. Also need to do these in VS2015 solution : (1) unload "built" folder, and (2) Add Content Include="Built\StarStar" in project file. The "built" folder contains the bundles and should appear greyed, otherwise more bad surprises and instabilities to deal with...
Build-Pass #2 task in VSTS BUILD allows to collect the fresh bundles generated by Build-Pass #1 and includes them automatically in the package to be published.
Without a second build-pass, collecting the bundles and merging them in the zip package is a nightmare, especially when you have 15,000 files to unzip then rezip (300 ms per file!!). Did not find file-merging capability that I could readily use in VSTS.
I have my hears to the ground listening for someone coming up with a more efficient CI/CD scheme for webpack. In the meanwhile, my 2-pass-build workaround is working flawlessly, but slow indeed.
I anticipate that the advances with ASP.NET core, Angular 2 and webpack will look into solving this elegantly.
I want to build an application that will be compatible with, say, Debian Lenny (libc, postgres, oracle and other libs) on a different Debian/Ubuntu release.
Is this possible? If so, where can I read how to do it?
You can use the open build service for this. Create the Debian package description files for it (you can add also rpm spec files), select the target distributions and you will get it built on each platform and also get a specific download repository for each platform. Your package will be rebuilt automatically when needed as well. You can install your own instance of the service if you need to host proprietary code.
If you want a multiplatform binary, you may want to build it against a LSB chroot:
http://ftp.linux-foundation.org/pub/lsb/impl
And bundle any library that is not part of it. The LSB has tools to then check your app for compliance. Their website is down right now, but it should be here: http://ldn.linuxfoundation.org/lsb/check-your-app