This repo contains attribute-driven-API cookbooks maintained by Facebook. It's a large chunk of what we refer to as our "core cookbooks."
It's worth reading our Philosophy.md doc before reading this. It covers how we use Chef and is important context before reading this.
It is important to note that these cookbooks are built using a very specific model that's very different from most other cookbooks in the community. Specifically:
- It assumes an environment in which you want to delegate. The cookbooks are designed to be organized in a "least specific to most specific" order in the run-list. The run-list starts with the "core cookbooks" that setup APIs and enforce a base standard, which can be adjusted by the service owners using cookbooks later in the run-list.
- It assumes a "run from main" type environment. At Facebook we use Grocery Delivery to sync the main branch of our source control repo with all of our Chef servers. Grocery Delivery is not necessary to use these cookbooks, but since they were built with this model in mind, the versions never change (relatedly: we do not use environments).
- It assumes you have a testing toolset that allows anyone modifying later cookbooks to ensure that their use of the API worked as expected on a live node before committing. For this, we use Taste Tester.
Cookbooks in this repo all being with fb_
to denote that not only do they
use the Facebook Cookbook Model, but that they are maintained in this repo.
Local cookbooks or cookbooks in other repositories that implement this model should not use this prefix, but should reference this document in their docs.
Unlike other cookbook models, we do not use resources as APIs, we use the node object. Configuration is modeled in arrays and hashes as closely and thinly as possible to the service we are configuring. Ideally, you should only have to read the docs to the service to configure it, not the docs to the cookbook.
For example, if the service we are configuring has a key-value pair configuration file, we will provide a simple hash where keys and values will be directly put into the necessary configuration file.
There are two reasons we use attribute-driven APIs:
-
Cascading configuration Since our cookbooks are ordered least specific (core team that owns Chef) to most specific (the team that owns this machine or service) it means that the team who cares about this specific instance can always override anything. This enables stacking that is not possible in many other models. For example, you can have a run-list that looks like:
- Core cookbooks (the ones in this repo)
- Site/Company cookbooks (site-specific settings)
- Region cookbooks (overrides for a given region/cluster)
- Application Category cookbooks (webserver, mail server, etc.)
- Specific Application cookbook ("internal app1 server")
So let's say that you want a specific amount of shared memory by default, but in some region you know you have different size machines, so you shrink it, but web servers need a further different setting, and then finally some specific internal webserver needs an even more specific setting... this all just works.
Further, a cookbook can see the value that was set before it modifies things, so the 'webserver' cookbook could look to see what the value was (small or large) before modifying it and adjust it accordingly (so it could be relative to the size of memory that the 'region' cookbook set).
Using resources for this does not allow this "cascading", it instead creates "fighting". If you use the cron resource to setup an hourly job, and then someone else creates a cron for that same job but only twice a day, then during each Chef run the cron job gets modified to hourly, then re-modified to twice a day.
-
Allows for what we refer to as "idempotent systems" instead of "idempotent settings." In other words, if you only manage a specific item in a larger config, and then you stop managing it, it should either revert to a less-specific setting (see #1) or be removed, as necessary.
For example let's say you want to set a cron job. If you use the internal cron resource, and then delete the recipe code that adds that cronjob, that cron isn't removed from your production environment - it's on all existing nodes, but not on any new nodes.
For this reason we use templates to take over a whole configuration wherever possible. All cron jobs in our
fb_cron
API are written to/etc/cron.d/fb_crontab
. If you delete the lines adding a cronjob, since they are just entries in a hash, when the template is generated on the next Chef run, those crons go away.Alternatively, consider a sysctl set by the "site" cookbook, then overwritten by a later cookbook. When that later code is removed, the entry in the hash falls back to being set again by the next-most-specific value (i.e. the "site" cookbook in this case).
How you formulate your run-lists is up to your site, as long as you follow the basic rule that core cookbooks come first and you order least-specific to most-specific. At Facebook, all of our run-lists are:
recipe[fb_init], recipe[$SERVICE]
Where fb_init
is similar to the sample provided in this repo, but with extra
"core cookbooks."
We generally think of this way: fb_init
should make you a "Facebook server"
and the rest should make you a whatever-kind-of-server-you-are.
Grab a copy of the repo, rename fb_init_sample
to fb_init
, and follow the
instructions in its README.md
(coordinating guidance is in comments in the default recipe).
It is often useful to factor out logic into a library - especially logic that doesn't create resources. Doing so makes this logic easier to unit test and makes the recipe or resource cleaner.
Our standard is that all cookbooks use the top-level container of module FB
,
and then create a class for their cookbook under that. For example, fb_fstab
creates a class Fstab
inside of the module FB
. We will refer to this as
the cookbook class from here.
We require all cookbooks use this model for consistency.
Since we don't put anything other than other classes inside the top-level
object, it's clear that a module
is the right choice.
While there is no reason that a cookbook class can't be one designed to be instantiated, more often than not it is simply a collection of class methods and constants (i.e. static data and methods that can then be called both from this cookbook and others).
Below the cookbook class, the author is free to make whatever class or methods they desire.
When building a complicated Custom Resource, the recommended pattern is to
factor out the majority of the logic into a module, inside of the cookbook
class, that can be include
d in the action_class
. This allows the logic to
be easily unit tested using standard rspec. It is preferred for this module to
be in its own library file, and for its name to end in Provider
, ala
FB::Thing::ThingProvider
.
When more than 1 or 2 methods from this module are called from the custom resource itself, it is highly recommended you include it in a Helper class for clarity, ala:
action_class do
class ThingHelper
include FB::Thing::ThingProvider
end
end
In this way, it is clear where methods come from.
You may have noticed that some of our cookbooks will extend the node
object,
while others have self-contained classes that sometimes require the node
be
passed as a parameter to some methods.
In general, the only time when extending the node
is acceptable is when
you are simply making a convenience function around using the node object. So,
for example, instead of making people do node['platform_family'] = 'debian'
,
there's a node.debian?
. This is simply syntactic sugar on top of data
entirely in the node.
In all other cases, one should simply have the node
be an argument passed on,
so as to not pollute the node namespace. For example, a method that looks at
the node attributes, but also does a variety of other logic, should be in a
cookbook class and take the node as an argument (per standard programming
paradigms about clear dependencies).
Sometimes it is convenient to put a method directly in a recipe. It is strongly preferred to put these methods in the cookbook class, however there are some cases where methods directly in recipes make sense. The primary example is a small method which creates a resource based on some input to make a set of loops more readable.
Methods should not be put into templates. In general, as little logic as possible should be in templates. In general the easiest way to do this is to put the complex logic into methods in your cookbook class and call them from the templates.
Chef is an ordered system and thus is designed to fail a run if a resource cannot be converged. The reason for this is that if one step in an ordered list cannot be completed, it's likely not safe to do at least some of the following steps. For example, if you were not able to write the correct configuration for a service, then starting it may open up a security vulnerability.
Likewise, the Facebook cookbooks will err on the side of failing if something seems wrong. This is both in line with the Chef philosophy we just outlined, but also because this model assumes that code is being tested on real systems before being released using something like taste-tester and that monitoring is in place to know if your machines are successfully running Chef.
Here are some examples of this philosophy in practice:
- If a cookbook is included on a platform it does not support, we
fail
. It might seem likereturn
ing in this case is reasonable but there is a good indication the run-list isn't as-expected, so it's a great idea to bail out before this machine is mis-configured. - If a configuration was passed in that we don't support, rather than ignore it
we
fail
.
Many cookbooks rely on the service underneath and the testing of the user to be the primary validator of inputs. Is the software we just configured, behaving as expected?
However, sometimes it's useful to do our own validation because there are certain configurations we don't want to support, because the software may accepted dangerous configurations we want to catch, or because the user could pass us a combination of configurations that is conflicting or impossible to implement.
In this model, however, this must be done at runtime. If your implementation is
done primarily inside of an internally-called resource, then this validation
can also be done there. However, if your implementation is primarily a recipe
and templates, doing the validation in templates is obviously not desirable.
This is where whyrun_safe_ruby_blocks
come in.
Using an ordinary ruby_block
would suffice to have ruby code run at runtime
to validate the attributes, however that means that the error would not be
caught in whyrun mode. Since this validation does not change the system, it is
safe to execute in whyrun mode, and that's why we use whyrun_safe_ruby_block
s:
they are run in whyrun mode.
It is worth noting that this is also where you can take input that perhaps was in a structure convenient for users and build out a different data structure that's more convenient to use in your template.
This model intentionally draws the complexity of Chef into the "core cookbooks" (those implementing APIs) so that the user experience of maintaining systems is simple and (usually) requires little more than writing to the node object. However, the trade-off for that simplicity is that implementing the API properly can be quite tricky.
How to do this is a large enough topic that it gets its own document. However, some style guidance is also useful. This section assumes you have read the aforementioned document.
The three main ways that runtime-safety is achieved are lazy
, templates
, and
custom resources
. When should you use which?
The template case is fairly straight forward - if you have a template, read the
node object from the within the template source instead of using variables
on the template resource, and all data read is inherently runtime safe since
templates run at runtime.
But what about lazy
vs custom resources
? For example, in a recipe you might
do:
package 'thingy packages' do
package_name lazy {
pkgs = 'thingy'
if node['fb_thingy']['want_devel']
pkgs << 'thingy-devel'
end
pkgs
}
action :upgrade
end
Where as inside of a custom resource you could instead do:
pkgs = 'thingy'
if node['fb_thingy']['want_devel']
pkgs << 'thingy-devel'
end
package pkgs do
action :upgrade
end
Which one is better? There's not an exact answer, both work, so it's a style consideration. In general, there are two times when we suggest a custom resource:
The first is when you need to loop over the node in order to even know what resources to create. Since this isn't possible to (well, technically it's possible with some ugliness, but by and large not using the standard DSL), this must go into a custom resource. Example might be:
# This MUST be inside of a custom resource!
node['fb_thingy']['instances'].each do |name, config|
template "/etc/thingy/#{instance}.conf" do
owner 'root'
group 'root'
mode '644'
variables({:config => config})
end
end
The second is when you're using lazy
on the majority of the resources in
your recipe. If your recipe has 15 resources and you've had to pepper all of
them with lazy
, it's a bit cleaner to make a custom resource that you call
in your recipe.
It's important here to reiterate: we're not referring to using a Custom Resource as an API, but simply making an internal custom resource, called only by your own recipe, as a way to simplify runtime safety.
Outside of these two cases, you should default to implementations inside of recipes. This is for a few reasons.
The first reason is that dropping entire implementations in custom resources leads to confusion and sets a bad precedent for how runtime-safety works. For example, consider the custom resource code we saw earlier where you assemble the package list in "naked" ruby:
pkgs = 'thingy'
if node['fb_thingy']['want_devel']
pkgs << 'thingy-devel'
end
This code works fine in a resource, but serves as a bad reference for others - since this absolutely won't work in a recipe (even though it'll run).
The second reason is that quite often implementations need both compile-time and runtime code, and by blindly dropping the implementation into a custom resource, you can often miss this and create bugs like this:
# only safe because we're in a custom resource
packages = FB::Thingy.determine_packages(node)
package packages do
action :upgrade
end
if node['fb_thingy']['want_cron']
node.default['fb_cron']['jobs']['thingy_runner'] = {
'time' => '* * * * *',
'command' => '/usr/bin/thingy --quiet',
}
end
service 'thingy' do
action [:enable, :start]
end
Note here that while this code all seems reasonable in a custom resource (if
statements are runtime safe when inside of a custom resource), that cronjob
will never get picked up, because you're using an API at runtime, but APIs must
be called at compile time and consumed at runtime. In reality, this needs to be
in the recipe in order to work, and should look like this, in a recipe:
package 'thingy packages' do
package_name lazy { FB::Thingy.determine_packages(node) }
action :upgrade
end
node.default['fb_cron']['jobs']['thingy_runner'] = {
'only_if' => proc { node['fb_thingy']['want_cron'] },
'time' => '* * * * *',
'command' => '/usr/bin/thingy --quiet',
}
service 'thingy' do
action [:enable, :start]
end
In general, always start your implementation as a recipe and then escalate to Custom Resources where necessary.
You can set up kitchen using the same commands as in .github/workflows/ci.yml
,
but once Chef runs you won't have access to connect, so modify
fb_sudo/attributes/default.rb
and uncomment the kitchen block.
Then you can do bundle exec kitchen login <INSTANCE>
after a failed
run, and sudo will be passwordless so you can debug.
See the LICENSE file in this directory
chef-cookbooks's People
Forkers
jaymzh davide125 miteshshah moandcompany cloudxtreme devopsbox eheydrick patcox shakespears nukepuppy simonvik ram-devsecops sundar85 jjam3774 akpatil darktul bigdatalyn parthmonga jasonwbarnett rlugojr knyy liangyu misheska qiushenglu runt18 tomchomiak gauravtayal0 rameshshihora elthariel daijingwu skywalk7 azaugg daniellawrence jaga6040 polinakud alexxnica kryndex dilippanwar1 barthclem nakul-0071 cwonrails jamsheer vishnupanati rstadeu hankshz dhirenshumsher mareksapota zealws seanpandrew shyam2205 vincentpanqi opportunitylivetv brnout mjsorribas ashi-austin aekondratiev wagnerpinheiro ykankaya jaketux8 ascdso2020 shantanupanda dnuang sagar2366 heliocampos es jjustice6 neuralnoise natewalck bhanditz chrisrlong codermaze warrelis paulyc roblox zhengqin djakobsson facebook-gad srinivasadhu greeneg mjabuz bwann johngidt vinayasathyanarayana kcbraunschweig vinted oko taskset sasg baisilg claretnnamocha rb2k chefaustin dreweasland joshuamiller01 akimdi holladay-io chmodawk naomireeves southgate isabella232chef-cookbooks's Issues
vs_ftpd service does not respect disable setting
https://github.com/facebook/chef-cookbooks/blob/master/cookbooks/fb_vsftpd/recipes/default.rb#L69
The disable vsftpd
service resource does not include service_name vsftpd
so it errors when node['fb_vsftpd']['enable'] == false
NoMethodError using fb_fstab on Ubuntu 18.04
Hi there,
I'm having an issue using fb_fstab on Ubuntu 18.04.
My Node looks like this:
{
"name": "somethingsomething",
"chef_environment": "prod",
"normal": {
"fb_fstab" : {
"enable_remount": true,
"enable_unmount": true,
"mounts" : {
"varlog" : {
"enable_remount": true,
"device": "logs-tmpfs",
"type": "tmpfs",
"opts": "size=1G",
"mount_point": "/var/log"
}
}
},
"tags": [ ]
},
"policy_name": null,
"policy_group": null,
"run_list": [
"recipe[fb_fstab::default]"
]
}
Running fb_fstab::default gives me a NoMethodError.
(the version Numbers are bumped, because we also use a version of this cookbook from like 2 years ago, this run used the cookbooks from d1e06db )
Starting Chef Client, version 14.10.9
resolving cookbooks for run list: ["fb_fstab::default"]
Synchronizing Cookbooks:
- fb_helpers (0.1.1)
- fb_fstab (0.0.2)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 5 resources
Recipe: fb_fstab::default
* file[/etc/.fstab.chef] action create
- change mode from '0644' to '0444'
* whyrun_safe_ruby_block[validate data] action run
================================================================================
Error executing action `run` on resource 'whyrun_safe_ruby_block[validate data]'
================================================================================
NoMethodError
-------------
undefined method `[]' for nil:NilClass
Cookbook Trace:
---------------
/var/chef/cache/cookbooks/fb_fstab/libraries/default.rb:98:in `get_autofs_points'
/var/chef/cache/cookbooks/fb_fstab/libraries/default.rb:105:in `autofs_parent'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:83:in `block (3 levels) in from_file'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:31:in `each'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:31:in `block (2 levels) in from_file'
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/fb_fstab/recipes/default.rb
28: whyrun_safe_ruby_block 'validate data' do
29: block do
30: uniq_devs = {}
31: node['fb_fstab']['mounts'].to_hash.each do |name, data|
32: # Handle only_if
33: if data['only_if']
34: unless data['only_if'].class == Proc
35: fail 'fb_fstab\'s only_if requires a Proc'
36: end
37: unless data['only_if'].call
38: Chef::Log.debug("fb_fstab: Not including #{name} due to only_if")
39: node.rm('fb_fstab', 'mounts', name)
40: next
41: end
42: end
43:
Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:28:in `from_file'
whyrun_safe_ruby_block("validate data") do
action [:run]
default_guard_interpreter :default
declared_type :whyrun_safe_ruby_block
cookbook_name "fb_fstab"
recipe_name "default"
block #<Proc:0x0000000003c16fa8@/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:29>
block_name "validate data"
end
System Info:
------------
chef_version=14.10.9
platform=ubuntu
platform_version=18.04
ruby=ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
program_name=/usr/bin/chef-client
executable=/opt/chef/bin/chef-client
Running handlers:
[2019-02-20T09:21:18+00:00] ERROR: Running exception handlers
Running handlers complete
[2019-02-20T09:21:18+00:00] ERROR: Exception handlers complete
Chef Client failed. 1 resources updated in 04 seconds
[2019-02-20T09:21:18+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2019-02-20T09:21:18+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2019-02-20T09:21:18+00:00] FATAL: NoMethodError: whyrun_safe_ruby_block[validate data] (fb_fstab::default line 28) had an error: NoMethodError: undefined method `[]' for nil:NilClass
this is the generated stacktrace:
Generated at 2019-02-20 09:21:52 +0000
NoMethodError: whyrun_safe_ruby_block[validate data] (fb_fstab::default line 28) had an error: NoMethodError: undefined method `[]' for nil:NilClass
/var/chef/cache/cookbooks/fb_fstab/libraries/default.rb:98:in `get_autofs_points'
/var/chef/cache/cookbooks/fb_fstab/libraries/default.rb:105:in `autofs_parent'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:83:in `block (3 levels) in from_file'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:31:in `each'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:31:in `block (2 levels) in from_file'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/provider/whyrun_safe_ruby_block.rb:25:in `action_run'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/provider.rb:182:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource.rb:578:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:70:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:98:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:98:in `each'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:98:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:103:in `iterate'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/resource_list.rb:92:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:97:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:720:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:715:in `catch'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:715:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:754:in `converge_and_save'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:286:in `run'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:321:in `block in fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:309:in `fork'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:309:in `fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:274:in `block in run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/local_mode.rb:44:in `with_server_connectivity'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:261:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:479:in `sleep_then_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:468:in `block in interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:467:in `loop'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:467:in `interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:451:in `run_application'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:66:in `run'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/bin/chef-client:25:in `<top (required)>'
/usr/bin/chef-client:74:in `load'
/usr/bin/chef-client:74:in `<main>'
>>>> Caused by NoMethodError: undefined method `[]' for nil:NilClass
/var/chef/cache/cookbooks/fb_fstab/libraries/default.rb:98:in `get_autofs_points'
/var/chef/cache/cookbooks/fb_fstab/libraries/default.rb:105:in `autofs_parent'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:83:in `block (3 levels) in from_file'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:31:in `each'
/var/chef/cache/cookbooks/fb_fstab/recipes/default.rb:31:in `block (2 levels) in from_file'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/provider/whyrun_safe_ruby_block.rb:25:in `action_run'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/provider.rb:182:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource.rb:578:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:70:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:98:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:98:in `each'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:98:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:103:in `iterate'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/resource_collection/resource_list.rb:92:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/runner.rb:97:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:720:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:715:in `catch'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:715:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:754:in `converge_and_save'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/client.rb:286:in `run'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:321:in `block in fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:309:in `fork'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:309:in `fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:274:in `block in run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/local_mode.rb:44:in `with_server_connectivity'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:261:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:479:in `sleep_then_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:468:in `block in interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:467:in `loop'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:467:in `interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application/client.rb:451:in `run_application'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/lib/chef/application.rb:66:in `run'
/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.10.9/bin/chef-client:25:in `<top (required)>'
/usr/bin/chef-client:74:in `load'
/usr/bin/chef-client:74:in `<main>
It seems like I'm missing something. Any Idea how I can get this cookbook to work?
Thanks,
-Markus
apt-key does not output short key IDs in debian 9
Hi,
The provider code:
if keys && keyring
installed_keys = []
if ::File.exist?(keyring)
cmd = Mixlib::ShellOut.new("LANG=C apt-key --keyring #{keyring} list")
cmd.run_command
cmd.error!
output = cmd.stdout.split("\n")
Chef::Log.debug("apt-key output: #{output.join("\n")}")
installed_keys = output.select { |x| x.start_with?('pub') }.map do |x|
x[%r{pub./(?[A-Z0-9])}, 'keyid']
end
end
Does not detect the debian 9 apt-key output:
pub rsa4096 2016-10-05 [SC]
72EC F46A 56B4 AD39 C907 BBB7 1646 B01B 86E5 0310
uid [ unknown] Yarn Packaging [email protected]
Every chef pass reinstalls all the keys.
fb_ntp shouldn't default to facebook timeservers
fb_postfix should not default mydomain to fb.com
We should use localhost instead
Publishing to supermarket.chef.io
Can we publish these to supermarket.chef.io ?
fix shellcheck issues in fb_ipset and fb_less
Regression with recent log output change
This change appears to cause a regression if node['fb_apt']['apt_update_log_path']
is not set.
9218cc5
It seems like the code should have curly braces instead:
execute 'apt-get update' do
command lazy {
log_path = node['fb_apt']['apt_update_log_path']
cmd_suffix = " >>#{Shellwords.shellescape(log_path)} 2>&1" if log_path
"apt-get update#{cmd_suffix}"
}
action :nothing
end
I'm getting the following error with this code when I try to use chef 18:
https://github.com/boxcutter/boxcutter-chef-cookbooks/actions/runs/7862940576/job/21452971460
================================================================================
Recipe Compile Error in /opt/kitchen/cache/cookbooks/boxcutter_init/recipes/default.rb
================================================================================
ArgumentError
-------------
tried to create Proc object without a block
Cookbook Trace: (most recent call first)
----------------------------------------
/opt/kitchen/cache/cookbooks/fb_apt/recipes/default.rb:99:in `block in from_file'
/opt/kitchen/cache/cookbooks/fb_apt/recipes/default.rb:98:in `from_file'
/opt/kitchen/cache/cookbooks/boxcutter_init/recipes/default.rb:35:in `from_file'
Relevant File Content:
----------------------
/opt/kitchen/cache/cookbooks/fb_apt/recipes/default.rb:
92: end
93:
94: fb_apt_sources_list 'populate sources list' do
95: notifies :run, 'execute[apt-get update]', :immediately
96: end
97:
98: execute 'apt-get update' do
99>> command lazy do
100: log_path = node['fb_apt']['apt_update_log_path']
101: cmd_suffix = " >>#{Shellwords.shellescape(log_path)} 2>&1" if log_path
102: "apt-get update#{cmd_suffix}"
103: end
104: action :nothing
105: end
106:
107: if Chef::VERSION.to_i >= 16
108: notify_group 'periodic package cache update' do
System Info:
------------
chef_version=18.2.7
platform=ubuntu
platform_version=20.04
ruby=ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]
program_name=/opt/cinc/bin/cinc-client
executable=/opt/cinc/bin/cinc-client
fb_apt update
Hello, we've written a version of fb_apt
that replaces use of apt-key
and /etc/apt/trusted.gpg.d
1 with per-repo keyrings managed by gpg
and specified via Signed-By
. It also uses the newer DEB822 format which we find easier to read and more concise in some cases. The cookbook API is similar except for the repos
and keys
attributes which are replaced with a sources
hash:
node.default['etsy_apt']['sources']['repo_name'] = {
'URIs' => 'https://repo.url.here',
'Suites' => 'noble',
'Components' => 'main',
'_public_key' => read_file('repo_name-signing-key'),
}
# or `_fingerprint` instead of `_public_key` to fetch from a keyserver
Presently it doesn't try to manage anything in /etc/apt/trusted*
nor accommodate older versions of Debian/Ubuntu or Chef.
We figure other users may want this functionality so contributing it back to this repo came up. Curious if the maintainers have a minimum level of back-compatibility they'd want before considering merging something like this, or if they'd be open to an fb_apt2
or something.
Happy to share code of course.
Footnotes
-
"The certificate MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by apt-key add." https://wiki.debian.org/DebianRepository/UseThirdParty โฉ
node.antlir_build? not defined in open source
Hi all, it looks like the node.antlir_build?
function is not defined that is referenced in the fb_syslog
cookbook:
Any chance of providing a definition for this in the open source fb_helpers
so we can use this cookbook unmodified, if it is needed?
fb_systemd::udevd fails on Ubuntu 20.04 LTS due to missing symlink
On Ubuntu 16 and 18 the fb_systemd::udevd
recipe succeeds without issue but on Ubuntu 20 the recipe will fail because the symlink from /sbin/udevadm
to /bin/udevadm
has been removed.
From the udev
filelists provided by Canonical for each release, one can validate the existence of /sbin/udevadm
in Xenial and Bionic Beaver, as well as its non-existence on Focal Fossa.
fb_zfs fails on every single supported distro
all centos and all debian/ubuntus fail for something equivalent to:
No candidate version available for spl, spl-dkms, zfs-dkms, zfsutils-linux
fb_storage always ignores override files when '_clowntown_override_file_method' not defined
According to both the docs and the logs, '_clowntown_override_file_method' allows you to add additional restrictions to when override files take effect, but if it's not defined, then they always take effect.
Turns out, this isn't true, we always return false. This is a simple bug, but fixing it it probably requires a slow rollout to FB so I haven't sent a PR.
Docs:
For additional safety, you can define a check method in
`node['fb_storage']['_clowntown_override_file_method']`
that will be invoked whenever override files are evaluated.
Actual code where we say we're ignore the method, but then returnf alse.
def override_file_applies?(verb, fname, quiet = false)
if File.exist?(fname)
base_msg = "fb_storage: System has #{fname} file present"
if node['fb_storage']['_clowntown_override_file_method']
...
end
unless quiet
Chef::Log.warn(
"#{base_msg} but the override check method is not defined, " +
'therefore we are ignoring it.',
)
end
return false # this should be `true`
end
return false
end
Definitions for antlir2 fix are not exposed in open source
Hi all - this commit seems to have definitions that aren't in the open source exposed to the public:
6baf374
I don't see a fb_util
or a definition for antlir2_build?
and this commit prevents use of fb_systemd
due to missing definitions.
fb_apache: hardcoded /etc/httpd path for server-status
This diff added a thing to write out status.conf, but it's hardcoded with /etc/httpd/ which breaks on non-CentOS systems. PR incoming eventually
Enablement of `unified_mode` for v17+ Chef client compatibility
Describe the Enhancement:
Converging the cookbooks in this repo on a v17+ Chef client result in the following deprecation warning being thrown at the end of the run (using fb_systemd
as an example):
The resource in the fb_systemd cookbook should declare `unified_mode true` at 2 locations:
- /var/chef/cache/cookbooks/fb_systemd/resources/loader_entries.rb
- /var/chef/cache/cookbooks/fb_systemd/resources/reload.rb
See https://docs.chef.io/deprecations_unified_mode/ for further details.
See: https://docs.chef.io/unified_mode/
Describe the Need:
Anyone using Chef client v17+ will face this deprecation warning until unified_mode true
is appended to the first line of each custom resource file.
Current Alternative
Ignore the deprecation warning.
Can We Help You Implement This?:
Should be a relatively easy PR (or series of PR's) to craft.
fb_vsftpd is broken on debian 9
fb_helpers_reboot lies about :now
:now
is suppsoed to reboot now (if allowed). But it has an undocumented FB-ism, that if you're in firstboot, it switches to managed reboots:
action :now do
# TODO (t15830562) - this action should observe required and override the
# same way as the :deferred action
if node['fb_helpers']['reboot_allowed']
if node.firstboot_any_phase?
set_reboot_override('immediate')
do_managed_reboot
else
That's... not cool.
fb_helpers contains namespace collisions with official chef node objects
In chef v17, chef added a lot of built-ins and we are seeing instability with at least one of them
when we call debian?
within a library function, it returns false, so we are now having to do debian? || ubuntu?
to workaround this as we consume fb_helpers.
To put this nicely, is Facebook willing to stop doing this? Or at the very least, stop putting so many of these things in node
and put it to a FB namespace?
validate the config in fb_apache
We should run httpd -t
in a validator when rendering config files in templates
fb_network_scripts changes should be reflected in /var/chef/backup
fb_network_scripts
does some trickery under the hood to in-place modify configs to try and avoid network restarts at much as possible. This is great, but the changes don't get reflected in /var/chef/backups
, making troubleshooting harder at times. I'm not entirely sure if this is something we can sanely improve, but filing this for tracking and visibility.
fb_apt doesn't take into account /etc/apt/trusted.gpg.d/
Debian and ubuntu both allow keys in /etc/apt/trusted.gpg.d
Currently if a key listed in chef is in a file in that directory, which for Ubuntu 18.04 all of the older keys are, then Chef won't find them, it tries to add them, this "succeeds" because it's already there and it tries to do this every time.
To make matters worse, apt-key
does not accept more than one --keyring
option.
I'm not sure of the best solution, but I suspect it's:
- Chef should use a keyring like
/etc/apt/trusted.gpg.d/fb_keyring.gpg
- Chef should, by default, cleanup keyrings that dont' match the format of
{ubuntu,debian}-keyring-\d{4}-.*.gpg
but should leave that and the main trusted.gpg alone as "the package's pervue" - Users should then only specify non-OS keys in chef.
codemod internal library methods in fb_fstab to make it clear they're not part of the API
Stuff like FB::Fstab.get_unmasked_base_mounts
isn't safe to call from random cookbooks as it relies on node data that may not necessarily be there or be correct. Audit all methods, codemod the internal ones with a _
and document the rest properly in README.
Compound API interactions for cookbooks included by `fb_init` are difficult to implement
Context
At Etsy, we've gone all-in on using this repository and the philosophy it represents (which we call the "Facebook pattern"), and have been working on refactoring our Chef code repository in a greenfield project.
As such, we've written an etsy_init
(i.e. fb_init
) cookbook that follows the same pattern as fb_init_sample
- we have a bunch of settings we configure for our "base", and then a number of include_recipe 'fb_foo'
statements to match.
We also apply our cookbooks with the run list as suggested by the README - recipe[fb_init], recipe[$SERVICE]
- where in our case $SERVICE
is hostgroup_foo
, i.e. a cookbook that configures everything necessary for a foo
cluster.
These "hostgroup" cookbooks often configure and include a cookbook that wraps some "Facebook-style" (our term) cookbooks, like fb_apache
, into a reusable building block that can be shared by nearly similar hostgroups. We refer to these as stack
cookbooks, but the naming isn't particularly important - what is important is that these cookbooks will almost always have "compound API interactions".
To make this more concrete, as an example we may have a stack_etsyweb
cookbook that:
- Sets up
fb_apache
- Installs php (imagine an
fb_php
cookbook) - Configures crons
- Etc.
...all for running "Etsyweb", our monolithic PHP application.
While the application itself is a monolith, we do run the application on separate clusters, and these clusters may be configured slightly differently. Due to this, our stack_etsyweb
cookbook will expose an API that a hostgroup_foo
can configure differently than a hostgroup_bar
would, but otherwise they are exactly the same.
The API exposed by stack_etsyweb
is, as mentioned above, a compound API interaction, and so it will set fb
attributes at runtime, like so:
whyrun_safe_ruby_block 'foo' do
block do
# ...
end
end
The Problem
We've run into an issue where we cannot configure Facebook cookbooks (using the compound API interaction pattern above) that have been included in fb_init
, because fb_init
converges before our "tier" cookbooks converge.
Building on the previous example, if our fb_init
cookbook looked like:
# ...
include_recipe 'fb_cron'
# ...
...and our stack_etsyweb
cookbook looked like:
whyrun_safe_ruby_block 'foo' do
block do
node.default['fb_cron']['jobs']['foo'] = {
'time' => '4 5 * * *',
'user' => 'apache',
'command' => "foo #{node['stack_etsyweb']['foo_cron_param']}",
}
end
end
...and our hostgroup_bar
cookbook looked like:
node.default['stack_etsyweb']['foo_cron_param'] = 'baz'
include_recipe 'stack_etsyweb'
...and finally, our run list looks like (as described in the README):
recipe[fb_init], recipe[hostgroup_bar]
...then we would unfortunately not see a foo
cron in the resulting crontab, because again, fb_cron
has already converged by the time that the stack_etsyweb
cookbook is converging.
While the example above demonstrates it with a cron, I'd like to emphasize that this happens for any compound API interaction involving a cookbook included in fb_init
.
This would also happen if we were to have two stack
cookbooks with a common dependency included in a single hostgroup
, like if hostgroup_foobar
included stack_foo
and stack_bar
, and if stack_foo
and stack_bar
both used fb_apache
. In this case, stack_bar
's compound API interactions with fb_apache
would never show up, since stack_foo
would converge fb_apache
before stack_bar
converged.
Discussion
First off, I realize the above has a lot of our own terminology in it, but hopefully the underlying problem is clear: compound API interactions require careful ordering to ensure that attributes written the converge phase are converged before the cookbooks that use them are converged.
It seems that you all have considered this issue on some level, as there are comments in the fb_init_sample
that mention ordering:
chef-cookbooks/cookbooks/fb_init_sample/recipes/default.rb
Lines 143 to 148 in e17c840
We've brainstormed this a bit internally, so I'd like to share some of the ideas we've had so far about how to handle this, in no particular order:
Somehow implement a "post-compile, pre-any-cookbook-convergence" phase, and set attributes there.
Since the issue boils down to wanting to set an attribute in the convergence phase so that it happens after the compile phase, but that causes ordering issues with the things that are being converged, we could implement some way of setting the attributes before any resources actually converge.
This could be something like a whyrun_safe_ruby_block
-esque custom resource that accumulates blocks at compile time and then have something at the top of fb_init
that executes all of them, or something like a pattern where cookbooks can register a recipes/converged-attributes.rb
file that we dynamically execute at the top of fb_init
somehow, etc.
Make an "fb_init
sandwich", and change the run list to something like ['fb_init::part_one', 'hostgroup_foo', 'fb_init::part_two']
.
I'm not a huge fan of this as we could have situations where we want something to live in "part one" and "part two", and so we'd have to pick whether we wanted to have it be set up early, or if we wanted to allow compound API interactions with it. It also doesn't solve the issue of having a hostgroup_foobar
that includes stack_foo
and stack_bar
.
Use lazy
node attributes via Chef::DelayedEvaluator
.
This one may require more explanation, but since this issue is already pretty long, I'll try to keep it brief. As of chef/chef#10345, Chef has some support for Chef::DelayedEvaluator
instances inside the node attribute tree. This means that instead of using a whyrun_safe_ruby_block
for a compound API interaction, you could write:
node.default['fb_cron']['jobs']['foo_cron'] = {
'time' => '4 5 * * *',
'user' => 'apache',
'command' => Chef::DelayedEvaluator.new { "foo #{node['stack_etsyweb']['foo_cron_param']}" },
}
This reads a lot better than the whyrun_safe_ruby_block
approach in my opinion, and also has the nice side-effect of still allowing for a "last-write wins" scenario where a later cookbook decides to overwrite the node.default['fb_cron']['jobs']['foo_cron']
entry entirely at compile time.
Unfortunately, this only works if the fb
cookbook in question accesses the node attributes directly via []
, and not via something like map
, each_pair
, to_h
, etc. As far as I can tell, most or all fb
cookbooks, like the aforementioned fb_cron
, do not access the attributes via []
, so this won't work.
I've documented this as a bug in the Chef repository in chef/chef#14159, because I believe that accessing the node attributes without []
should still evaluate any Chef::DelayedEvaluator
s anyway, but alternatively Facebook cookbooks could be changed to expect Chef::DelayedEvaluator
instances until the behavior is changed (if ever). This would potentially be something like walking the node attribute tree to evaluate Chef::DelayedEvaluator
s manually before iterating over the node attributes, or always using []
, or something else.
We've considered doing that, but it means that we'd need to make a lot of changes to our fork of this repository. We wanted to get your opinion on the matter first before we more seriously considered this approach, since we'd ideally like to contribute these changes here.
Closing
Off the cuff, I think that being able to use Chef::DelayedEvaluator
instances in the attribute tree is pretty attractive, but the "post-compile, pre-any-cookbook-convergence" phase idea is probably more tractable.
In any case, we're interested in getting your thoughts on this issue, and we're curious if you all have implemented anything or follow any patterns internally in order to better allow for compound API interactions in all situations.
@jaymzh in particular, I'm curious what your take is on either this issue or on the one I filed with Chef at chef/chef#14159, since I saw you participated in chef/chef#10861.
Thanks for giving this a read, and let me know if I can clarify anything! I'm also happy to take this conversation elsewhere.
Fix CI failures
several shellcheck failures for fb_network_scripts/files/default/ifup-pre-local
kitchen failures for unknown instance:
- /usr/bin/kitchen test default-debian-10
- /usr/bin/kitchen test default-ubuntu-2004
- /usr/bin/kitchen test default-centos-8
kitchen failures for grub:
template[grub2_config_efi] action create
Parent directory /boot/efi/EFI/debian does not exist.
various rubocop failures
Cleanup the fb_systemd rollout
Its sitting at in_shard?(99)... wanna clean that up?
fb_reprepro needs love
I'm leaving it out of my testing PR, but it needs defaults for all it's values in attributes...
Thought to be honest, I would actually pull all that configurability of what it's directories are out to match the rest of the cookbooks that let you put whatever you want in the config, but are strongly opinionated about where that config is laid out.
get_seeded_flexible_shard in fb_cron appears to be missing from public repo
When you set splaysecs
the fb_cron
cookbook references the node.get_seeded_flexible_shard()
. This method does not appear to be publicly available.
Small copy-pasta in the fb_ethtool README.md
References fb_screen
when it should be fb_ethtool
:
"You can opt out of package management by settings node['fb_screen']['manage_packages'] to false."
fb_tmpclean doesn't include tmpreaper defaults on debian/ubuntu - breaks /tmp cleanup
default file doesn't run tmpreaper for anything by default and only adds new calls based on what people add to the API. The default API does not include anything in directories
(presumably because tmpclean file always does /tmp hardcoded), but the template for tmpreaper drops that. The default file on Ubuntu btw has:
TMPREAPER_TIME=${TMPREAPER_TIME:-7d}
TMPREAPER_PROTECT_EXTRA=${TMPREAPER_PROTECT_EXTRA:-''}
TMPREAPER_DIRS=${TMPREAPER_DIRS:-'/tmp/.'}
nice -n10 tmpreaper --delay=$TMPREAPER_DELAY --mtime-dir --symlinks $TMPREAPER_TIME \
$TMPREAPER_ADDITIONALOPTIONS \
--ctime \
--protect '/tmp/.X*-{lock,unix,unix/*}' \
--protect '/tmp/.ICE-{unix,unix/*}' \
--protect '/tmp/.iroha_{unix,unix/*}' \
--protect '/tmp/.ki2-{unix,unix/*}' \
--protect '/tmp/lost+found' \
--protect '/tmp/journal.dat' \
--protect '/tmp/quota.{user,group}' \
`for i in $TMPREAPER_PROTECT_EXTRA; do echo --protect "$i"; done` \
$TMPREAPER_DIRS
in it.
It's probably better to move away from the templating of calls and instead template /etc/tmpreaper.conf and just populate the right variables.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.