When we make a change to a file, we currently have to build an image, deploy new Kubernetes configs,Īnd wait for Kubernetes to schedule the pod. Pretty good! But Tilt has some tricks up its sleeve to make it even faster. Here’s what our timing looks like now: Approach (For more on the principles at work here, check out this guide.)
#Tilt to live sample code how install#
Hooray, we’re now using the cache instead of running yarn install for every single build. (Click the screenshot to see an interactive view.) Here’s what it looks like when we build with our new Dockerfile: Dependency installation now uses the cache instead of actually running a long, slow command. With a little rearranging, our new Dockerfile looks like this: This is a hint that we can optimize our Dockerfile to be smarter about caching. The first thing I notice when I click “deploy” is a bunch of logs from yarn install and not just once, but every dang time. Can we do better? Step 2: Why Is the Docker Build So Slow? Tilt offers you some default benchmarks, and the tools to capture your own. To schedule the process, and the time until the server is ready to serve There are many benchmarks we care about-the time to build the image, the time If you look closely, the elapsed time displayed in the Tilt sidebar is different (Click the screenshot to see an interactive view.) Approach See that button next to the deploy resource? Let’s click it and see what happens! Clicking the button triggers the 'deploy' local_resource, which in turn kicks off an update to the server.
(We’ve added a new dep for this purpose: the templating engine mustache-express.) Whenever the app starts up, it calls getSecsSinceDeploy(), calculates the time elapsed, and displays that value in the served webpage. Const fs = require ( ' fs ' ) let timeSince = ' N/A '.
0 kommentar(er)
